Che cos'è una Webhook Retry Policy?

Una politica di ritentativi webhook è un insieme di regole che un sistema webhook utilizza per determinare se rinviare un webhook in caso di insuccesso. Questa configurazione specifica il limite di tentativi del sistema, la pausa tra ogni tentativo, i criteri di fallimento e le condizioni per l'interruzione. Nella maggior parte delle politiche, viene impiegato il backoff esponenziale per prevenire tentativi in brevi intervalli di tempo, mentre gli eventi che falliscono permanentemente vengono inviati a una coda di messaggi non recapitabili.

Le politiche di riprovo sono una considerazione rilevante, dato che reti e servizi possono presentare variazioni di affidabilità. La finalizzazione dei trasferimenti di dati durante interruzioni di rete o del servizio nella consegna dipende dalla presenza di una politica di riprovo attiva. Una politica di riprovo previene la perdita di dati da un errore di consegna assicurando un riprovo dopo che l'estremità ricevente non restituisce un 2xx.

Quando un tentativo di consegna di un evento riscontra un problema, la politica del sistema di solito lo elabora esaminando il codice di stato HTTP. Successivamente, viene introdotta una pausa, in linea con uno schema di ritentativi, prima che la trasmissione dell’evento venga ritentata. Questi sono i componenti:

•       Condizioni di attivazione: gli stati HTTP precisi che attivano un nuovo tentativo.
•       Schema di ritentativi: intervalli di tempo tra i tentativi, normalmente backoff esponenziale o un valore estratto dall'header Retry-After.
•       Segnalazione dei fallimenti: implica funzioni che consentono l'identificazione di problemi senza una risoluzione immediata, come un'indicazione del prossimo tentativo.
•       Osservabilità e idempotenza: log, metriche e strumenti di riproduzione per l'analisi dei fallimenti, insieme alla gestione idempotente per gestire i duplicati.

La maggior parte delle strategie di retry incorpora un ritardo nell'intervallo tra i tentativi. Quella più spesso seguita è l'exponential backoff; prolunga il periodo di attesa ad ogni tentativo, il che, a sua volta, riduce il carico su un ricevitore che soffre di qualche tipo di problema.

Questo significa:

•       Backoff esponenziale: è una tecnica in cui i tentativi di ripetizione sono separati da periodi di tempo progressivamente più lunghi.
•       Aggiungere jitter: variando il tempo di attesa con un elemento casuale per evitare picchi di tentativi contemporanei. Twilio Event Streams implementa l'idea di jitter per evitare una “thundering herd”.
•       Tentativi a più livelli: immediato, a breve termine, a lungo termine e coda per i messaggi non elaborabili.

Questa coda è destinata agli eventi che hanno utilizzato i loro processi di riprova configurati senza raggiungere uno stato di completamento. Questi eventi sono conservati in una posizione designata, consentendo l'esame delle loro specificità, l'osservazione della loro sequenza o la loro gestione a seconda delle necessità.

Piuttosto che copiare ciecamente politiche di retry aggressive, una buona progettazione dei retry considera quando il sistema potrebbe essere sovraccaricato da troppi tentativi. Ciò implica una riflessione attenta sui limiti dei tentativi e sulla tempistica degli intervalli.

•       Preferire il backoff esponenziale più il jitter.
•       Stabilire limiti di riprovo ben definiti e criteri di arresto.
•       Stabilire regole inequivocabili relative ai codici di stato per determinare quali consegne verranno ritentate e quali no.
•       Le chiavi di idempotenza si riferiscono alla gestione coerente della rielaborazione.

Le pratiche di monitoraggio si riferiscono all'identificazione di discrepanze nella consegna della pipeline in una fase iniziale. Tracciare le metriche che indicano problemi, quindi notificare automaticamente tramite avvisi e collegarli agli strumenti utilizzati per l'operatività.

•       I dashboard: una panoramica sullo stato di consegna per l'ultimo periodo di tempo.
•       Replay manuale: un'opzione che consente di inviare nuovamente gli eventi dopo che la causa principale è stata risolta.
•       Runbook: presentano azioni predefinite per gli ingegneri on-call, intese a guidare il processo di risoluzione dei problemi.

•       Un processo che tenta metodicamente di riprovare le consegne fallite mira a risolvere i casi in cui gli eventi potrebbero altrimenti rimanere non elaborati.
•       Contribuisce a ridurre la probabilità di perdita di dati degli eventi durante interruzioni a breve termine e ritardi nelle consegne.
•       Le integrazioni in genere si riprendono da brevi periodi di interruzione, con i problemi associati che sono spesso temporanei piuttosto che causare interruzioni prolungate.
•       La consegna costante di dati critici, come ordini e pagamenti, è un fattore che influenza il livello di fiducia nelle integrazioni.