Wat is een Webhook herhaalpogingsbeleid?

Een webhook-retrybeleid is een reeks regels die een webhook-systeem gebruikt om te bepalen of een webhook opnieuw moet worden verzonden bij mislukking. Deze configuratie specificeert de limiet van het systeem op pogingen, de pauze tussen elke poging, de criteria voor mislukking en de voorwaarden voor stopzetting. In de meeste beleidsregels wordt exponentiële backoff toegepast om pogingen binnen korte tijdsbestekken te voorkomen, terwijl permanent falende gebeurtenissen naar een dead-letter queue worden gestuurd.

Beleid voor herhaalpogingen is een belangrijke overweging, gezien netwerken en diensten variaties in betrouwbaarheid kunnen vertonen. De afronding van gegevensoverdrachten tijdens netwerk- of serviceverstoringen bij de levering is afhankelijk van de aanwezigheid van een actief beleid voor herhaalpogingen. Een beleid voor herhaalpogingen voorkomt gegevensverlies door een mislukte levering door een herhaalpoging te garanderen nadat de ontvangende partij geen 2xx retourneert.

Wanneer een poging tot gebeurtenislevering op een probleem stuit, verwerkt het beleid van het systeem dit doorgaans door de HTTP-statuscode te onderzoeken. Hierna wordt een pauze ingelast, conform een herkansingsschema, voordat de gebeurtenisoverdracht opnieuw wordt geprobeerd. Dit zijn de componenten:

•       Triggercondities: de precieze HTTP-statussen die een nieuwe poging activeren.
•       Herkansingsschema: tijdsintervallen tussen pogingen, normaal gesproken exponentiële backoff of een waarde geëxtraheerd uit de Retry-After header.
•       Fouten zichtbaar maken: het omvat functies die de identificatie van problemen mogelijk maken zonder een onmiddellijke oplossing, zoals een indicatie van het tijdstip van de volgende poging.
•       Observeerbaarheid en idempotentie: logs, metrics en replay-tools voor foutanalyse, samen met idempotente verwerking om duplicaten op te vangen.

De meeste strategieën voor opnieuw proberen passen een vertraging toe in het interval tussen pogingen. Degene die het vaakst wordt gevolgd, is exponentiële backoff; deze verlengt de wachttijd bij elke poging, wat op zijn beurt de belasting verlaagt voor een ontvanger die kampt met een probleem.

Dit betekent:

•       Exponentiële backoff: is een techniek waarbij herhaalde pogingen worden gescheiden door steeds langere tijdsperioden.
•       Jitter toevoegen: de wachttijd variëren met een willekeurig element om te voorkomen dat herhaalpogingen tegelijkertijd pieken. Twilio Event Streams implementeert het idee van jitter om een “thundering herd” te voorkomen.
•       Getrapte herhaalpogingen: onmiddellijk, korte termijn, lange termijn en dead-letterwachtrij.

Deze wachtrij is bedoeld voor gebeurtenissen die hun geconfigureerde herpogingsprocessen hebben benut zonder een voltooide status te bereiken. Deze gebeurtenissen worden bewaard op een aangewezen locatie, wat het mogelijk maakt om hun details te onderzoeken, hun volgorde te observeren, of ze aan te pakken zoals de situatie dit vereist.

In plaats van agressief herstelbeleid blindelings te kopiëren, houdt een goed ontwerp voor herpogingen rekening met wanneer het systeem overweldigd kan raken door te veel herpogingen. Dit betekent dat er zorgvuldig moet worden nagedacht over herpogingslimieten en de timing van intervallen.

•       Geef de voorkeur aan exponentiële back-off plus jitter.
•       Stel goed gedefinieerde herpogingslimieten en stopcriteria vast.
•       Stel eenduidige statuscoderegels vast voor welke leveringen opnieuw worden geprobeerd en welke niet.
•       Idempotentiesleutels hebben betrekking op het consistent beheer van herverwerking.

Monitoringpraktijken hebben betrekking op de identificatie van afwijkingen in de pipeline-levering in een vroeg stadium. Volg metrics die problemen aanduiden, meld dan automatisch via waarschuwingen en koppel deze aan de tools die voor de operatie worden gebruikt.

•       Dashboards: een overzicht van de leveringsstatus voor de afgelopen periode.
•       Handmatige herhaling: een optie die het mogelijk maakt om gebeurtenissen opnieuw te versturen nadat de hoofdoorzaak is opgelost.
•       Runbooks: ze presenteren voorgedefinieerde acties voor on-call engineers, bedoeld om het probleemoplossingsproces te begeleiden.

•       Een proces van het methodisch opnieuw proberen van mislukte leveringen is gericht op het aanpakken van gevallen waarbij gebeurtenissen anders onverwerkt zouden blijven.
•       Het draagt bij aan een kleinere kans op verlies van gebeurtenisgegevens tijdens kortstondige onderbrekingen en leveringsvertragingen.
•       Integraties herstellen doorgaans van korte periodes van verstoring, waarbij de bijbehorende problemen vaak tijdelijk van aard zijn in plaats van langdurige uitval te veroorzaken.
•       De consistente levering van cruciale gegevens, zoals bestellingen en betalingen, is een factor die het vertrouwen in integraties beïnvloedt.