Webhook affidabili: idempotenza, retry e monitoraggio
Evita ordini duplicati e guasti silenziosi con tre pratiche essenziali per i webhook in produzione.
Un webhook che funziona in prova non è necessariamente affidabile in produzione. Interruzioni temporanee, risposte lente ed eventi ripetuti sono normali. Idempotenza, retry controllati e monitoraggio rendono prevedibile l’integrazione.
Gli eventi duplicati sono normali
Il mittente può non sapere se il destinatario ha elaborato la richiesta. La connessione può interrompersi dopo l’elaborazione ma prima della conferma, causando un nuovo invio.
Il destinatario deve prevedere una consegna almeno una volta. Ogni evento richiede un identificatore stabile, registrato prima di creare ordini o addebiti.
I retry richiedono regole
Tentativi immediati aumentano il carico durante un guasto. Usa intervalli progressivi e una piccola variazione per evitare il ritorno simultaneo di migliaia di eventi.
Gli errori temporanei tornano in coda. Quelli permanenti, come payload non validi, devono essere analizzati senza cicli infiniti.
Cosa registrare
- ID evento e origine
- Orari di ricezione e conclusione
- Stato HTTP e categoria errore
- Numero del tentativo
- Record interessato
- Tempo di elaborazione
Avvisi davvero utili
Controlla tasso di errore, profondità della coda, età dell’evento più vecchio e messaggi scartati. Definisci responsabili e una procedura di rielaborazione idempotente.
Un pannello semplice deve mostrare salute, ritardo ed eventi che richiedono intervento umano.
Conclusione
L’affidabilità nasce da guasti visibili e recuperabili. Introduci identificatori, registro di elaborazione, backoff e una coda delle eccezioni.
Perguntas frequentes
Che cos’è l’idempotenza?
È la capacità di ricevere più volte lo stesso evento senza ripeterne l’effetto.
Ogni errore richiede un retry?
No. Solo gli errori temporanei; un payload non valido richiede correzione.
Qual è l’avviso più importante?
L’età dell’evento più vecchio rivela subito l’accumulo di ritardo.