Les retries sont souvent présentés comme une forme inoffensive de résilience. En production, ils font partie des moyens les plus rapides d’amplifier une mauvaise hypothèse. Une politique de retry mal conçue transforme un incident ponctuel en duplication d’effets de bord, saturation de queue et confusion support.
Le vrai sujet d’ingénierie consiste à décider quand le système doit cesser d’être optimiste.
Le problème
Les équipes ajoutent des retries avant d’avoir défini les frontières d’idempotence, les classes d’erreur ou le passage en dead-letter. Le système “continue d’essayer” sans savoir s’il protège la cohérence ou s’il génère davantage de dégâts.
Ce qui casse en pratique
- Un worker rejoue un appel partenaire qui avait déjà réussi et déclenche des doublons.
- Les erreurs transitoires et structurelles sont traitées de la même manière, ce qui remplit la queue avec du travail sans issue.
- Les opérateurs savent qu’un job a échoué cinq fois, mais pas si un replay est sans danger.
- Le backoff retarde la visibilité de l’incident : le système semble actif alors qu’il ne progresse pas réellement.
Décisions de conception
- Classer les erreurs en retryable, non-retryable et review-opérateur afin que le worker cesse de deviner.
- Rendre les opérations à effets de bord idempotentes avant d’autoriser les retries automatiques.
- Persister compteur de tentatives, dernière erreur et éligibilité au replay avec l’état du job.
- Envoyer rapidement en dead-letter les jobs structurellement cassés au lieu de protéger artificiellement les métriques.
Arbitrages
- Des politiques conservatrices réduisent le risque caché mais exposent certains incidents plus tôt.
- L’infrastructure d’idempotence ajoute de l’état et du coût de coordination.
- Le dead-letter handling crée plus de travail opérationnel explicite, mais c’est préférable à de l’incohérence silencieuse.
Patterns de production
- Retries bornés avec backoff exponentiel et limites dépendantes de la classe d’erreur.
- Clés d’idempotence ou enregistrements de déduplication pour les effets de bord visibles.
- Dead-letter queues avec métadonnées structurées d’échec.
- Outils de replay nécessitant une décision opérateur pour les jobs à état externe ambigu.
Ce que je ferais différemment
- Ajouter des dashboards par classe d’échec avant de déployer les retries automatiques.
- Traiter les changements de politique de retry comme des changements produit, pas comme un simple réglage infra.
- Outiller plus tôt l’approbation de replay afin d’éviter les relances hasardeuses depuis un shell.