Les workflows asynchrones paraissent propres sur un diagramme d’architecture et désordonnés pendant un incident. Le mode de panne n’est presque jamais “la queue est down”. C’est plutôt “le workflow tourne encore, mais personne ne peut dire si un replay est sûr”.
La fiabilité en production vient d’un traitement récupérable, pas seulement différé.
Le problème
Les équipes déplacent souvent un traitement long en arrière-plan sans décider quel état fait autorité, comment les retries doivent se comporter ni quels échecs nécessitent une intervention humaine plutôt qu’une nouvelle tentative automatique.
Ce qui casse en pratique
- Le traitement s’exécute deux fois parce que la requête a été rejouée après un timeout côté utilisateur.
- Un effet de bord réussit chez un partenaire mais le worker tombe avant d’enregistrer le succès localement.
- Les opérateurs voient “queued” ou “failed” sans savoir si un replay est sûr.
- Le travail de fond finit après une autre action utilisateur, ce qui crée des attentes contradictoires.
Décisions de conception
- Persister l’état du workflow avant d’envoyer les effets de bord afin de disposer d’un point d’ancrage durable pour support et replay.
- Considérer les retries comme un choix de conception, pas comme un rattrapage opérationnel.
- Exposer le statut du workflow dans un langage métier plutôt que dans le vocabulaire de la queue.
- Séparer la logique de transition d’état des actions aval comme notifications ou synchronisations partenaires.
Arbitrages
- Une architecture async récupérable demande plus d’état persistant et plus d’outillage opérateur qu’un simple “fire and forget”.
- Des retries sûrs réduisent la corruption silencieuse mais augmentent la complexité.
- La visibilité opérationnelle coûte du temps en amont, mais bien moins qu’un débogage sur un état opaque.
Patterns de production
- États de jobs explicites comme
queued, running, failed, completed, replay-required.
- Handlers idempotents pour emails, synchronisation partenaire et webhooks.
- Dead-letter queues enrichies de catégories d’échec plutôt que d’exceptions brutes.
- Audit trails liant action métier, tentative worker et mutation finale.
Ce que je ferais différemment
- Ajouter plus tôt un vrai outillage de replay au lieu de laisser la récupération à des scripts ad hoc.
- Classer les échecs selon l’impact métier et pas seulement selon le type technique.
- Donner plus d’attention aux “succès tardifs”, souvent à l’origine des tickets support les plus confus.