Qu'est-ce qu'une politique de réessai de webhook ?

Une politique de réessai de webhook est un ensemble de règles qu'un système de webhook utilise pour déterminer s'il doit renvoyer un webhook en cas d'échec. Cette configuration spécifie la limite de tentatives du système, la pause entre chaque tentative, les critères d'échec et les conditions d'arrêt. Dans la plupart des politiques, un backoff exponentiel est utilisé pour éviter les tentatives dans de courts laps de temps, tandis que les événements en échec permanent sont envoyés à une file d'attente de lettres mortes.

Les politiques de réessai sont une considération pertinente, étant donné que les réseaux et services peuvent présenter des variations de fiabilité. La finalisation des transferts de données lors de perturbations du réseau ou du service de livraison dépend de la présence d'une politique de réessai active. Une politique de réessai prévient la perte de données due à un échec de livraison en garantissant un réessai si le destinataire ne renvoie pas de code 2xx.

Lorsqu'une tentative de livraison d'événement rencontre un problème, la politique du système traite généralement cela en examinant le code de statut HTTP. Suite à cela, une pause est introduite, conformément à un calendrier de nouvelle tentative, avant que la transmission de l'événement ne soit tentée à nouveau. Voici les composants :

•       Conditions de déclenchement: les statuts HTTP précis qui déclenchent une nouvelle tentative.
•       Calendrier de nouvelle tentative: intervalles de temps entre les tentatives, normalement un délai d'attente exponentiel ou une valeur extraite de l'en-tête Retry-After.
•       Remontée des échecs: cela implique des fonctions qui permettent l'identification des problèmes sans résolution immédiate, telle qu'une indication du prochain temps de réessai.
•       Observabilité et idempotence: journaux, métriques et outils de relecture pour l'analyse des échecs, ainsi qu'une gestion idempotente pour absorber les doublons.

La plupart des stratégies de réessai intègrent un délai dans l'intervalle entre les tentatives. La plus fréquemment adoptée est le backoff exponentiel ; il prolonge la période d'attente à chaque tentative, ce qui, à son tour, allège la charge d'un récepteur rencontrant un problème.

Cela signifie :

•       Backoff exponentiel: est une technique où les tentatives de réessai sont espacées par des périodes de temps de plus en plus longues.
•       Ajouter de la gigue: varier le temps d'attente par un élément aléatoire afin d'éviter les pics de nouvelles tentatives simultanées. Twilio Event Streams met en œuvre l'idée de la gigue pour éviter un « effet de troupeau ».
•       Réessais échelonnés: immédiates, à court terme, à long terme et file d'attente des messages non distribués.

Cette file d'attente est destinée aux événements qui ont utilisé leurs processus de nouvelle tentative configurés sans atteindre un statut terminé. Ces événements sont conservés dans un emplacement désigné, permettant d'examiner leurs spécificités, d'observer leur séquence ou de les traiter selon ce que la situation exige.

Plutôt que de copier aveuglément des politiques de nouvelle tentative agressives, une bonne conception des nouvelles tentatives tient compte du moment où le système pourrait être submergé par un trop grand nombre de tentatives. Autrement dit, cela implique de réfléchir attentivement aux limites de nouvelles tentatives et au timing des intervalles.

•       Privilégiez le backoff exponentiel avec gigue.
•       Établir des limites de tentatives et des critères d'arrêt bien définis.
•       Établir des règles de codes de statut claires indiquant quelles livraisons seront relancées et lesquelles ne le seront pas.
•       Les clés d'idempotence sont liées à la gestion cohérente du retraitement.

Les pratiques de surveillance sont liées à l'identification des écarts dans la livraison des pipelines à un stade précoce. Suivez les métriques qui indiquent des problèmes, puis notifiez automatiquement via des alertes et liez-les aux outils utilisés pour l'exploitation.

•       Les tableaux de bord: un aperçu de la santé de la livraison pour la dernière période.
•       Relecture manuelle: une option qui permet d'envoyer à nouveau des événements après la résolution de la cause première.
•       Runbooks: ils présentent des actions prédéfinies pour les ingénieurs d'astreinte, destinées à guider le processus de dépannage.

•       Un processus visant à retenter méthodiquement les livraisons échouées a pour but de traiter les cas où les événements pourraient autrement rester non traités.
•       Il contribue à réduire la probabilité de perte de données d'événement lors des interruptions de courte durée et des retards de livraison.
•       Les intégrations se rétablissent généralement après de courtes périodes de perturbation, leurs problèmes associés étant souvent temporaires plutôt que de causer des pannes prolongées.
•       La livraison constante de données critiques, telles que les commandes et les paiements, est un facteur influençant le niveau de confiance dans les intégrations.