WebhookIO
Tecnico

Misure critiche per evitare di perdere richieste Webhook

WebhookIO Team •
#webhook#affidabilità#devops#best-practices
Affidabilità Webhook - Sicurezza dei Dati

I webhook sono fantastici, finché il tuo server di destinazione non si blocca o la connessione di rete cade. I webhook operano per natura secondo il principio “invia e dimentica” (fire and forget), ma nei processi aziendali critici (come ricevere pagamenti), “dimenticare” non è un’opzione.

In questo articolo, esamineremo come puoi rendere la tua architettura webhook più resiliente e come ridurre la perdita di dati allo 0%.

1. Gestione del Timeout

Il servizio che invia il webhook non aspetta una risposta per sempre. Di solito c’è un periodo di timeout di 5-10 secondi. Se il tuo endpoint non risponde entro questo tempo, la richiesta è considerata fallita.

Soluzione: Non eseguire mai operazioni di lunga durata (creazione di PDF, invio di e-mail, reportistica di database) sull’endpoint che riceve il webhook. L’unica cosa che devi fare è:

  1. Ricevere la richiesta.
  2. Metterla in coda (Queue).
  3. Restituire 200 OK al mittente.
  4. Eseguire l’operazione in background (Background Worker).

2. Meccanismo di Riprova (Retry)

Ogni sistema può bloccarsi. Il tuo server potrebbe essere in manutenzione o potrebbe esserci un errore di rete istantaneo. In questi casi, il webhook non deve andare perso.

Exponential Backoff: Invece di riprovare immediatamente una richiesta fallita, il metodo più sano è provare aumentando il tempo di attesa.

Controlla assolutamente la politica di riprova del tuo provider webhook (ad esempio, Stripe). Imposta anche assolutamente una strategia di riprova nei tuoi invii webhook.

3. Idempotenza

Il meccanismo di riprova è fantastico ma ha un effetto collaterale pericoloso: La stessa richiesta arriva più di una volta. Se la risposta 200 OK non raggiunge il mittente a causa di un errore di rete, il mittente invia nuovamente lo stesso webhook. Se il tuo codice non è preparato per questo, potresti addebitare il cliente due volte o creare record duplicati nel database.

Soluzione: C’è un ID univoco (Event ID) in ogni richiesta webhook. Conserva questo ID nel tuo database o Redis.

if redis.exists(event_id) {
    return 200 OK; // Già elaborato, non farlo di nuovo.
}
process_payment();
redis.save(event_id);

4. Sicurezza e Verifica (HMAC)

Poiché il tuo endpoint è pubblico, persone malintenzionate possono inviare richieste webhook false. Per prevenire ciò, è obbligatorio verificare la firma HMAC (Hash-based Message Authentication Code). Il mittente esegue l’hash del payload con una chiave segreta e lo invia nell’header. Tu esegui la stessa operazione e controlli se corrisponde.

5. Dead Letter Queue (DLQ)

Cosa succede se tutti i tentativi di riprova falliscono? Invece di eliminare i dati, spostali in un’area separata chiamata “Dead Letter Queue”. Puoi esaminare manualmente i record errati qui in seguito ed elaborarli nuovamente dopo aver risolto il problema.

Costruire un’architettura webhook affidabile richiede gestione delle code, strategie di riprova e misure di sicurezza.

Se non vuoi costruire tutta questa infrastruttura (Queue, Retry, DLQ, Logging) da zero, puoi utilizzare un Webhook Gateway come WebhookIO. WebhookIO riceve tutte le richieste in entrata per te, le mette in coda e te le consegna in modo sicuro quando il tuo endpoint è pronto.

← Back to Blog