Délai aléatoire avant réessai
Le jitter fait varier aléatoirement les délais pour étaler les nouvelles tentatives de plusieurs clients.
Le retry jitter introduit une part aléatoire dans l’attente avant un nouvel appel. Il répartit dans le temps les tentatives de plusieurs clients. Il est particulièrement utile lorsque de nombreux clients constatent la même panne au même moment : une pause identique peut simplement reporter le prochain pic de charge.
Trois clients, des attentes différentes
Dans un exemple fictif, trois clients peuvent chacun choisir une attente aléatoire dans une fenêtre de 0–2 s avant leur prochaine tentative. Ils attendent par exemple 0.4 s, 1.1 s et 1.7 s. Ces valeurs illustrent la répartition ; elles ne constituent pas une configuration recommandée. Des tentatives peuvent encore coïncider malgré ces délais aléatoires.
La stratégie de réessai détermine toujours les erreurs qui justifient une nouvelle tentative, le nombre de tentatives autorisées et la durée totale maximale. Les consignes du système destinataire concernant l’attente doivent être respectées. Avec un backoff exponentiel, la plage d’attente augmente généralement au fil des tentatives jusqu’à un plafond défini ; le jitter fait varier la pause effective selon la règle utilisée.
Le hasard ne rend pas la répétition d’une opération sûre. Une réponse perdue peut masquer une écriture déjà effectuée. Avant de réessayer, l’intégration doit donc disposer d’une règle de répétition sûre, par exemple l’idempotence ou une vérification du résultat.
Sources
Termes associés
- Stratégie de nouvelle tentativeUne stratégie de nouvelle tentative précise quels échecs relancer, avec quels délais et jusqu’à quelle limite.
- IdempotenceUne opération idempotente produit le même effet sur l’état, qu’elle soit exécutée une seule fois ou répétée à l’identique.
- Inbox transactionnelleUne inbox transactionnelle utilise des enregistrements durables de messages pour protéger le traitement local contre les livraisons en double.
- Acquittement de messageUn acquittement indique au courtier de messages qu’une livraison a été reçue ou traitée selon la règle convenue.
- Espace client de testUn espace client logiquement délimité d’une application multilocataire, configuré pour les vérifications.
- Rejeu de webhookLe rejeu de webhook renvoie une notification déjà envoyée. La reprise volontaire et les attaques par rejeu nécessitent des contrôles différents.
Articles sur le sujet
Interfaces & intégration avec ASES
ERP, CRM et boutique bien connectés