Architecture événementielle : dans quels cas est-elle réellement utile ?

Distinguer événement, commande et tâche

Un événement décrit un fait survenu, par exemple qu’une demande a été acceptée. Une commande demande une action à un destinataire responsable de son traitement. Une tâche différée organise une exécution ultérieure. Ces notions peuvent utiliser les mêmes outils de transport, mais leurs contrats et leurs responsabilités diffèrent.

La distinction aide à éviter des échanges ambigus. Un message présenté comme un événement mais qui exige qu’un service précis réalise immédiatement une action peut conserver une forte dépendance. Nommer correctement l’intention permet de définir qui décide, qui peut refuser et comment le résultat est connu.

Il faut aussi distinguer communication événementielle et conservation d’un historique complet d’événements comme source de vérité. Ce second choix, souvent appelé event sourcing, ajoute d’autres contraintes de modèle et d’évolution. Il n’est pas nécessaire pour utiliser des événements entre composants.

Identifier les situations où le différé apporte une valeur

Un traitement long peut être déplacé hors du parcours interactif si l’utilisateur n’a pas besoin de son résultat immédiatement. Une importation, une génération de document ou une préparation de données peut alors être suivie par un état d’avancement. Le produit doit expliquer ce qui est accepté et ce qui reste en cours.

Plusieurs consommateurs peuvent aussi réagir à un même fait pour des besoins distincts. Une mise à jour peut alimenter une recherche et un traitement analytique sans imposer que les deux se terminent avant la réponse initiale. Cette autonomie n’existe réellement que si les contrats et les défaillances sont gérés séparément.

L’absorption de pics constitue un autre cas possible. Une file peut lisser le travail dans le temps, mais elle ne crée pas de capacité infinie. Il faut connaître la vitesse de traitement, la taille de l’attente acceptable et les conséquences d’un retard durable.

Vérifier que la cohérence différée est acceptable

Lorsqu’un échange devient asynchrone, les différentes vues du système peuvent être temporairement désynchronisées. Une modification peut être enregistrée alors que son reflet dans la recherche n’est pas encore visible. Le métier doit savoir si cette situation est acceptable et comment elle est présentée.

Certains parcours demandent une réponse immédiate ou une cohérence forte entre plusieurs données. Les rendre événementiels peut créer des états intermédiaires complexes. Il faut alors définir les réservations, les expirations et les compensations nécessaires, ou conserver une opération locale plus simple.

Prévoir les doublons, les reprises et l’ordre

Un message peut être traité puis reçu à nouveau si l’accusé de traitement n’a pas été enregistré. Le consommateur doit donc éviter de produire deux fois un effet qui doit rester unique. Cette propriété, l’idempotence, doit être conçue à partir de l’opération métier et des identifiants disponibles.

L’ordre d’arrivée ne correspond pas toujours à l’ordre logique attendu. Plusieurs producteurs, reprises ou partitions peuvent modifier la séquence observée. Le contrat doit préciser si l’ordre importe et sur quel périmètre il peut être garanti. À défaut, le consommateur doit pouvoir reconnaître un état ancien ou incomplet.

Les reprises automatiques doivent être bornées et observables. Une erreur temporaire peut justifier une nouvelle tentative ; une donnée invalide ne sera pas corrigée par une répétition infinie. Les messages qui restent en échec demandent une responsabilité et une procédure de traitement explicites.

Éviter la perte entre la base et la publication

Un producteur peut modifier sa base puis échouer avant de publier le message correspondant. L’inverse peut aussi produire un événement qui ne correspond pas à un état finalement conservé. Cette frontière entre persistance et communication doit être étudiée ; elle ne disparaît pas parce que le broker fonctionne correctement.

Des mécanismes comme une boîte d’envoi transactionnelle peuvent rapprocher l’écriture métier et l’intention de publication dans une même transaction locale. Ils introduisent néanmoins un traitement supplémentaire, des reprises et une surveillance. Leur pertinence dépend du niveau de fiabilité demandé et de l’architecture existante.

La promesse d’un traitement « exactement une fois » doit être examinée sur l’ensemble du parcours, y compris les effets externes. Une propriété du transport ne garantit pas automatiquement qu’un paiement, un courriel ou une écriture tierce ne sera jamais répété. Les responsabilités doivent être définies à chaque frontière.

Concevoir l’observabilité avant l’incident

Dans un parcours différé, l’utilisateur peut attendre alors qu’aucune requête HTTP n’est encore ouverte. Il faut pouvoir relier sa demande aux messages, aux traitements et aux erreurs associés. Des identifiants de corrélation et des états lisibles aident à suivre le parcours sans exposer de données sensibles.

Les indicateurs utiles incluent l’âge des messages en attente, les erreurs répétées et la progression des traitements critiques. Le nombre de messages seul peut être trompeur si leur coût varie fortement. Les alertes doivent être reliées à un impact et à une action possible.

L’équipe doit disposer d’une procédure de reprise contrôlée. Rejouer un lot peut corriger un retard ou multiplier un effet mal protégé. Les outils d’exploitation doivent donc tenir compte de l’idempotence, des droits d’accès et de la traçabilité des interventions.

Comparer avec une solution plus simple

Une tâche en arrière-plan dans une application unique peut suffire à un besoin de différé. Un appel synchrone peut rester préférable si la réponse est immédiatement nécessaire et que les dépendances sont limitées. L’architecture événementielle doit être choisie pour un bénéfice identifié, pas pour suivre une tendance.

Le coût comprend les contrats, les versions de messages, la surveillance, les tests de défaillance et la formation de l’équipe. Il faut aussi prévoir comment un consommateur rejoint le système et comment un ancien contrat est retiré. Ces responsabilités persistent après le premier développement.

Une expérimentation utile doit provoquer des échecs : indisponibilité d’un consommateur, doublon, retard et message invalide. Si l’équipe ne sait pas expliquer ce qui se passe dans ces cas, la démonstration nominale ne suffit pas à valider la décision.

Une fiche de contrat pour chaque échange critique

Décrivez le fait ou la demande transportée, son producteur, ses destinataires et la signification de ses identifiants. Précisez les données nécessaires, les règles d’évolution du format et la durée pendant laquelle un ancien message peut encore être reçu. Ajoutez le comportement attendu en cas de doublon, de retard et de rejet. La fiche doit également indiquer qui surveille les échecs et qui autorise un rejeu. Ces éléments donnent un support commun aux développeurs, aux responsables produit et à l’exploitation. Ils ne remplacent pas les tests, mais rendent leurs scénarios explicites. Un contrat qui ne décrit que le format JSON laisse encore ouvertes les questions qui déterminent la fiabilité du parcours.

Décider à partir du parcours métier

Commencez par un schéma du parcours et de ses états. Indiquez ce qui doit être immédiat, ce qui peut attendre et ce qui doit être compensé en cas d’échec. Puis examinez les besoins d’autonomie et les capacités d’exploitation. Cette démarche permet de choisir un périmètre cohérent.

Trame peut analyser une proposition événementielle, une intégration existante ou les difficultés d’un système déjà distribué. Le travail porte sur les contrats, les modes de défaillance et la compréhension du parcours, avant de recommander un outil.

Les technologies de messagerie ont des caractéristiques différentes, mais aucune ne remplace cette conception. L’accompagnement vise une décision argumentée et une exploitation comprise par l’équipe, sans promesse générale de performance ou de disponibilité.