Les nouvelles tentatives : quand elles vous sauvent et quand elles aggravent tout
Par L'équipe Atflow
Relancer une opération en échec est le motif de fiabilité le plus courant, et l'un des plus faciles à faire catastrophiquement mal. Bien fait, les échecs transitoires disparaissent avant que quiconque ne les remarque. Mal fait, vos propres clients achèvent un service qui peinait déjà à tenir.
Ne relancer que ce qui peut l'être
Un timeout mérite une nouvelle tentative ; une erreur 400 non, et ce ne sera jamais le cas. Relancer une panne déterministe revient simplement à échouer plus lentement tout en générant de la charge. La première décision consiste toujours à savoir si cette classe d'erreur peut réussir à une seconde tentative.
Les règles qui comptent
- Un backoff exponentiel avec jitter — des relances synchronisées forment une avalanche auto-infligée.
- Un plafond strict de tentatives et une destination définie pour ce qui les a épuisées.
- L'idempotence, sinon votre nouvelle tentative débite le client deux fois.
- Un circuit breaker, pour cesser de marteler ce qui est manifestement hors service.
Ce sont des décisions de politique, pas des détails de code — c'est pourquoi elles méritent d'être visibles. Une branche de relance indiquant « +72 h, max 3 » est auditable ; une constante enfouie dans un service ne l'est pas.