Un utilisateur clique sur « Générer la facture ». L’écran répond que la demande est terminée, mais le PDF n’arrive jamais. Le worker a épuisé ses tentatives après une erreur de stockage et le message attend dans une file connue seulement des développeurs. Le problème se voit dans les trois vérités incompatibles : pour le métier, la facture existe ; pour l’application, un travail technique a échoué ; pour le support, aucun état ne permet de les réconcilier.
Le vrai sujet de Messenger est l’attente assumée par le produit. Il ne s’agit pas seulement de rendre le contrôleur plus rapide, mais de gérer le délai et les erreurs entre l’intention et le résultat. Le produit doit enregistrer la commande, exposer son état, tolérer une redélivrance et donner une reprise aux opérations. Sans ces éléments, la file déplace seulement la panne hors de la requête utilisateur.
Contrairement à ce que suggère une file, un traitement synchrone bien borné reste souvent plus résilient qu’un asynchronisme opaque. Messenger apporte de la valeur lorsque la durée, la variabilité d’un partenaire ou une pointe de charge justifie l’état intermédiaire. Sa mécanique de transports et de retries ne fournit ni effet exactement unique ni décision métier. Ces propriétés appartiennent à l’application.
Dans une application issue d’un développement web sur mesure, la messagerie doit être conçue avec le support et l’exploitation. Cette méthode part du service rendu, qualifie les erreurs, instrumente la file et répète la reprise avant d’élargir le trafic.
Vérifier que l’asynchronisme résout le bon problème
Nommer la contrainte avant le transport
Une opération peut être longue, sensible aux pointes ou dépendante d’un tiers instable. Chaque cause appelle une réponse différente. Une tâche CPU lourde peut utiliser des workers dédiés ; un partenaire lent exige timeout et temporisation ; une rafale peut être lissée si le délai est acceptable. Messenger ne doit pas masquer une requête SQL inefficace ou un contrat métier confus.
Le cadrage définit temps de réponse de l’écran, délai maximal avant résultat, perte acceptable et conséquence d’un doublon. Il précise aussi qui agit quand le délai est dépassé. Ces éléments déterminent le transport, la concurrence et le statut visible.
Garder synchrone ce qui doit réussir ensemble
Valider une règle et écrire l’état qui prouve cette validation appartiennent souvent à la même transaction locale. Les séparer crée une fenêtre où l’utilisateur croit avoir agi sans preuve durable. Le message intervient après l’enregistrement de l’intention, pour une conséquence dont le délai est explicitement accepté.
Changer la promesse visible pour l’utilisateur
La réponse HTTP confirme que la demande est reçue, pas que son effet est terminé. L’interface expose reçu, en cours, réussi, refusé et résultat inconnu. Elle indique la dernière mise à jour et la prochaine action possible. Un échec technique n’est pas présenté comme un refus métier.
Une commande possède un identifiant stable. L’utilisateur peut revenir sans soumettre une deuxième fois. Le support recherche cet identifiant et retrouve messages, tentatives et effet produit. Le produit évite ainsi que le bouton de relance devienne une source de doublons.
Conserver une issue quand le système doute
Après un timeout, le partenaire peut avoir accepté la demande. Le statut « résultat inconnu » suspend la relance automatique et déclenche un rapprochement. Cette nuance protège davantage qu’un simple rouge ou vert, car elle évite de confondre absence de réponse et absence d’effet.
Concevoir un message stable et intentionnel
Le message décrit une intention ou un fait avec identifiant, version et références nécessaires. Il n’embarque pas une entité Doctrine détachée ni tout le contexte utilisateur. Le handler recharge l’état actuel, contrôle les préconditions et produit un résultat explicite.
La documentation officielle de Messenger décrit bus, transports, routage, retries et file d’échec. Ces mécanismes restent séparés du contrat métier. Le nom « EnvoyerFacture » exprime une responsabilité mieux qu’un message générique « ProcessDocument ».
Versionner ce qui traverse le temps
Un message peut rester en file pendant un déploiement. Le nouveau code doit comprendre la version en attente ou migrer la file de manière contrôlée. Ajouter un champ optionnel est plus sûr que changer le sens d’une valeur. Les consommateurs inconnus sont inventoriés avant toute rupture.
Rendre chaque effet tolérant aux redélivrances
La plupart des transports fonctionnent au moins une fois : un message peut être traité, puis redélivré si l’acquittement se perd. Le handler vérifie si l’effet attendu existe déjà. Une clé métier unique, une table de déduplication ou le contrat du partenaire peut fournir cette preuve.
L’idempotence ne signifie pas ignorer toutes les répétitions. Une seconde demande réellement distincte doit rester possible. La clé représente l’intention, par exemple facture et version, pas seulement l’utilisateur. Le résultat déjà produit est renvoyé ou relié au message répété.
Tester après l’effet et avant l’acquittement
Le scénario critique interrompt le worker après l’écriture externe mais avant l’accusé. À la reprise, le même message ne produit ni second paiement ni second document. Cette panne simulée donne une preuve plus utile qu’un test où le handler échoue avant tout effet.
Réserver les retries aux erreurs temporaires
Une indisponibilité réseau ou une limitation de débit peut justifier une nouvelle tentative. Une donnée invalide, une permission refusée ou un contrat incompatible ne guérira pas avec le temps. Le handler classe l’erreur et choisit retry, rejet définitif ou intervention.
La temporisation évite d’aggraver l’incident. Elle tient compte du délai métier. Dix tentatives sur deux heures peuvent être pertinentes pour une synchronisation et inacceptables pour une révocation urgente. La politique est donc attachée au flux, pas copiée globalement.
Borner l’orage de reprises
Quand le partenaire revient, tous les messages ne doivent pas repartir simultanément. La concurrence et le débit sont limités. Une priorité protège les opérations urgentes. Le monitoring observe l’âge du plus ancien message, car une file stable en volume peut contenir quelques dossiers bloqués depuis trop longtemps.
Traiter la file d’échec comme une file métier
La file d’échec n’est pas une poubelle. Chaque entrée possède une catégorie, une corrélation, le dernier état connu et une action. Les erreurs de données rejoignent une file de correction ; les incidents techniques attendent la restauration ; les contrats inconnus déclenchent une escalade.
Le support ne relance pas aveuglément. Il vérifie l’état externe, corrige la cause autorisée puis rejoue une commande idempotente. La relance conserve auteur, motif et lien vers l’échec initial. La suppression définitive exige une décision et une preuve de non-effet.
Mesurer l’âge plutôt que le seul volume
Une file de dix messages peut être critique si l’un bloque une clôture depuis un jour. Les tableaux distinguent âge, valeur métier et capacité de reprise. L’alerte mène à un runbook précis au lieu de simplement signaler « messages failed ».
Cas concret : générer et transmettre une facture
Cas concret hypothétique. Après validation d’une livraison, une application génère un PDF, le stocke et transmet une référence au portail client. Le traitement synchrone dépasse parfois trente secondes. Les utilisateurs rafraîchissent, créant plusieurs demandes, et une panne de stockage laisse le statut « facturé » sans document.
La cible enregistre FactureÀProduire et une entrée outbox dans la même transaction. Un handler génère le document avec une clé facture-version, vérifie son empreinte, stocke la référence puis publie FactureDisponible. L’interface suit la production séparément de la validité comptable.
Le pilote traite cinq cents factures et simule vingt interruptions. Le seuil local exige zéro document dupliqué, cent pour cent des échecs corrélés et une reprise en moins de quinze minutes par le support. Un document sans statut ou un statut sans document bloque l’extension. Ces seuils appartiennent à ce flux et à cette équipe.
Décider le mode dégradé
Si le stockage est indisponible, la facturation peut continuer uniquement si le métier accepte un document différé et si l’état est visible. Sinon, la validation est suspendue. Le mode dégradé est une décision produit, pas un comportement inventé par le worker au moment de l’incident.
Relier transaction locale et publication fiable
Écrire la donnée puis publier peut perdre le message si le processus tombe entre les deux. Publier puis écrire peut déclencher un traitement sans état local. Une outbox enregistre l’événement dans la transaction, puis un relais le transmet. Cette approche accepte un délai et des redélivrances.
Le handler limite sa transaction locale et évite les appels réseau sous verrou. Il enregistre intention et résultat séparément lorsque le partenaire est externe. Une compensation explicite corrige l’état si le métier l’autorise ; elle ne prétend pas remonter le temps.
Préparer le déploiement compatible
Producteurs et consommateurs peuvent tourner avec deux versions pendant le déploiement. Le message reste compris dans cette fenêtre. Un changement incompatible utilise une nouvelle version ou un nouveau type. La file existante est vidée, migrée ou conservée avec son ancien consommateur selon un plan vérifié.
Observer délai, âge et résultat des messages
L’instrumentation relie commande, message, tentative, effet et statut visible. Les logs portent corrélation et catégorie sans données sensibles. Les métriques suivent débit, durée de traitement, âge du plus ancien, retries et échecs définitifs. Une trace seule n’offre pas un pilotage métier.
Le seuil d’alerte dépend de la promesse. Pour le pilote de facture, un âge supérieur à dix minutes peut déclencher une vérification, puis vingt minutes un mode dégradé. Ce budget local est ajusté après mesure. Il ne devient pas une norme Messenger applicable à tous les transports.
Relier chaque alerte à une responsabilité
L’alerte nomme l’équipe, le runbook et le geste autorisé. Une indisponibilité partenaire, un worker saturé et une donnée invalide ne suivent pas la même escalade. Le monitoring sans action attribuée produit seulement du bruit.
Donner au support une reprise bornée
L’outil de support affiche contexte minimal, dernier état, tentatives et preuve externe. Il autorise rapprocher, corriger une donnée bornée, rejouer ou escalader selon le rôle. Il interdit la modification arbitraire du payload et l’effacement silencieux.
La procédure commence par vérifier si l’effet existe déjà. Elle choisit ensuite la commande de reprise, contrôle le résultat et clôt le dossier avec un motif. Le développeur intervient pour une catégorie inconnue ou un défaut de contrat, pas pour chaque message ordinaire.
Répéter la reprise avant la production
Une personne du support traite un message dupliqué, une donnée refusée et un partenaire silencieux dans l’environnement de recette. Le temps, les hésitations et les accès manquants sont relevés. Le runbook est corrigé avant l’ouverture.
Savoir quand Messenger vaut son coût
Messenger convient aux tâches longues, aux intégrations fragiles, aux traitements différables et aux pointes que le métier accepte de lisser. Il est aussi utile quand plusieurs transports doivent partager une orchestration et une supervision cohérentes.
Il vaut moins pour une opération courte qui doit confirmer immédiatement un invariant. Une table de tâches et un cron peuvent suffire à un petit besoin batch. Le choix le plus simple reste celui dont l’échec et la reprise sont compris par l’équipe.
Erreurs fréquentes qui rendent la file opaque
Envoyer une entité Doctrine
L’entité sérialisée vieillit, contient trop de données et dépend du mapping. Le message porte une intention et des références. Le handler recharge ce dont il a besoin et vérifie l’état actuel.
Relancer toutes les erreurs
Un retry sur une donnée invalide remplit la file et masque le défaut. Les erreurs sont classées ; les définitives rejoignent une correction ou une décision.
Confondre file acceptée et travail terminé
L’interface annonce un succès trop tôt et pousse l’utilisateur à agir sur un état absent. Le produit expose le délai et rafraîchit le résultat sans nouvelle soumission.
Arbitrer synchronisme, batch ou messagerie
La matrice compare besoin de réponse, volume, variabilité, tolérance au délai, coût d’un doublon et capacité de support. Un traitement synchrone gagne lorsque la transaction est courte et indivisible. Un batch gagne pour un lot planifié. Messenger gagne pour une commande individualisée dont le délai et la reprise sont explicites.
- D’abord, conserver le synchronisme si l’utilisateur doit connaître la décision et si l’effet tient dans la transaction.
- Ensuite, choisir un batch lorsque le lot et sa fenêtre portent mieux le besoin que des messages individuels.
- Puis, adopter Messenger si le délai, les retries et la corrélation créent une valeur exploitable.
- Enfin, refuser l’asynchronisme tant que le statut inconnu et le rollback restent sans responsable.
Plan d’action pour un premier flux
Semaine une : fermer la promesse
Produit et support choisissent une opération, définissent statuts, délai, erreurs et effet d’un doublon. Ils fixent le seuil d’arrêt et la responsabilité de chaque issue. L’entrée et la sortie sont observables.
Semaine deux : construire le contrat
Le message, la clé d’idempotence, les dépendances et la transaction sont définis. Les tests provoquent redélivrance, timeout et donnée refusée. La journalisation relie commande et effet.
Semaine trois : installer l’exploitation
Monitoring, alertes, file d’échec et runbook sont configurés. Les retries ont un budget et une temporisation. Le support exécute rapprochement, repli et reprise avec ses vrais droits.
Semaine quatre : ouvrir et décider
Un trafic limité mesure âge, taux d’erreur, doubles effets et temps de récupération. Le dossier final décrit responsabilités, instrumentation, seuils et rollback. L’équipe élargit seulement si la promesse visible correspond aux sorties réellement produites.
La répétition finale arrête le worker après l’effet externe, restaure le transport et injecte une réponse partenaire ambiguë. Le support rapproche la commande, contrôle l’idempotence et choisit retry, repli ou escalade depuis le runbook. Le test doit préserver la qualité de la décision métier, pas seulement ramener la longueur de file à zéro.
Le compte rendu relie chaque seuil au workflow, à son impact business et à une responsabilité. Il inventorie les dépendances, la journalisation, la gouvernance des accès et le monitoring. Une architecture asynchrone reste refusée si l’équipe ne sait pas expliquer la sortie d’un message, contenir un orage de retries ou restaurer le service après un rollback.
La mise en production commence sur une catégorie de factures et une plage de débit bornée. Les opérations observent l’âge, les erreurs définitives et le temps utile de reprise pendant plusieurs jours. Elles élargissent lorsque les résultats restent sous les seuils locaux ; sinon, elles corrigent le contrat ou reviennent au traitement précédent sans perdre les demandes acceptées.
La capacité des workers est augmentée seulement après avoir vérifié le goulot réel. Ajouter des consommateurs peut déplacer la saturation vers la base ou le partenaire et accélérer l’incident. Le test relève concurrence, connexions, mémoire et limites externes ; le réglage garde une marge pour les flux prioritaires et documente le retour à la capacité nominale.
Le déploiement est répété avec des messages de l’ancienne version encore en attente. Le nouveau consommateur doit les comprendre ou le plan conserve temporairement l’ancien code. La CI construit l’artefact, teste le contrat sérialisé et vérifie le mode dégradé. Cette compatibilité protège les commandes acceptées pendant une livraison, lorsque la file traverse nécessairement deux versions applicatives.
La revue associe enfin la capacité technique à un coût de support. Elle compte les dossiers rapprochés, les relances évitées et les interventions développeur, sans attribuer automatiquement toute amélioration à Messenger. Si la file ajoute plus de diagnostic qu’elle n’en retire, le comité simplifie le flux ou revient au synchronisme sur le périmètre concerné.
Guides complémentaires pour fiabiliser le run
Observer le workflow
Observer un workflow métier aide à relier métriques techniques, états visibles et action du support.
Tester les exceptions
Tester un workflow et ses exceptions approfondit doublons, délais et reprises.
Structurer le projet Symfony
Organiser un domaine Symfony situe les messages dans des frontières métier explicites.
- Écrire la promesse et les états avant de choisir le transport.
- Tester une redélivrance après l’effet et un partenaire au résultat inconnu.
- Faire exécuter la reprise par les opérations avant d’augmenter le trafic.
Conclusion : asynchroniser sans perdre la décision
Messenger aide le run lorsqu’il rend un délai et des erreurs explicitement gérables. La file devient alors une capacité du produit, pas un détail caché derrière le contrôleur.
Messages stables, idempotence, retries qualifiés et états visibles protègent la causalité. Le support peut expliquer et reprendre sans créer un second effet.
Le premier flux doit rester borné et mesuré. Si le statut inconnu, la file d’échec ou le rollback ne sont pas maîtrisés, le traitement synchrone peut rester le meilleur choix.
Dawap peut cadrer la promesse, instrumenter Messenger et répéter la reprise dans un accompagnement en développement web sur mesure conçu avec les équipes produit et opérations.
