On présente souvent l’architecture asynchrone comme un sujet de performance. En pratique, le bénéfice principal est le contrôle opérationnel. Une bonne architecture de queue isole le travail instable de la partie du produit que l’utilisateur doit pouvoir croire immédiatement.
La vraie question n’est pas “est-ce que ça peut partir en async ?” mais “qu’est-ce qui doit être vrai avant la fin de la requête ?”
Le problème
Quand des handlers HTTP génèrent des documents, appellent des API partenaires, envoient des notifications et modifient l’état dans un seul chemin d’exécution, la latence côté produit et la gestion d’échec en production deviennent étroitement couplées.
Ce qui casse en pratique
- Des timeouts HTTP surviennent alors que l’écriture autoritaire a déjà réussi, ce qui pousse les clients à rejouer.
- Un travail lourd bloque des parcours produit qui devraient seulement enregistrer l’intention et l’état.
- Les workers héritent d’une logique métier qui n’a jamais été rendue explicite côté domaine.
- Les équipes voient la profondeur de queue mais restent incapables de dire quel parcours utilisateur est en risque.
Décisions de conception
- Garder dans la requête la validation et l’écriture autoritaire, pas les effets de bord lourds.
- Traiter les workers comme des unités runtime à part entière, avec ownership, monitoring et delivery séparés.
- Écrire un événement d’audit au moment où le travail est mis en queue afin que le support voie l’intention avant la fin.
- Placer les intégrations fragiles derrière des frontières async pour qu’une dépendance instable ne gouverne pas le parcours utilisateur.
Arbitrages
- Sortir du travail du cycle de requête améliore la résilience mais retire une partie de la certitude immédiate côté utilisateur.
- Des runtimes séparés réduisent le couplage mais agrandissent la surface de déploiement et de monitoring.
- Des queues auditables ajoutent de l’état à gérer, mais cela vaut mieux qu’un traitement opaque.
Patterns de production
- État durable persisté avant publication du job.
- Payloads de queue explicites avec identifiants, corrélation et contexte de replay.
- Tableaux de bord workers montrant retries, classe d’échec et dernier checkpoint utile.
- Budgets de temps clairs entre ce qui doit finir en requête et ce qui peut se terminer plus tard.
Ce que je ferais différemment
- Rendre le versioning des payloads plus explicite plus tôt pour éviter les couplages cachés.
- Suivre les budgets de latence par workflow plutôt que la seule profondeur de queue.
- Standardiser plus tôt les outils de replay afin que la récupération ne dépende pas de scripts d’ingénieur.