Une PME e-commerce me contacte après un week-end de soldes raté. À chaque commande validée, leur code envoyait l’email de confirmation de manière synchrone, en attendant la réponse du serveur de mail. Le serveur de mail rame. L’envoi traîne, et la commande entière met dix secondes à se boucler. Au pic, les commandes dépassaient le délai d’attente maximal et étaient abandonnées par le système (elles « timeoutaient »). Des clients prêts à payer abandonnaient à cause d’un email qui n’avait rien à voir avec l’acte d’achat. Le correctif n’a pas été d’acheter un plus gros serveur de mail. Il a fallu sortir l’envoi du chemin critique : la commande publie un fait, « commande validée », et continue ; l’email part de son côté, quand le service mail peut le traiter.
C’est exactement le genre de bascule où l’événementiel mérite sa place. Reste à savoir l’identifier sans en mettre partout. Voici comment je procède, dans l’ordre.
L’événementiel découple les composants et absorbe les pannes des consommateurs, mais rend le flux plus dur à suivre. Je l’adopte là où un même fait déclenche plusieurs réactions ou doit partir en asynchrone, et je garde l’appel direct quand l’appelant attend le résultat pour continuer.
-
Je liste les réactions à un même fait. Une commande validée déclenche l’email, la facturation, la mise à jour du stock, l’alimentation des statistiques. En appel direct, ces quatre dépendances s’empilent dans le code de la commande, qui finit par tout connaître. L’événement renverse ça. Dès qu’un fait intéresse plusieurs consommateurs indépendants, l’émetteur publie et ignore qui l’écoute. Vous ajoutez un cinquième abonné sans rouvrir le code qui émet.
-
Je repère ce qui n’a aucune raison de rester synchrone. L’email du cas plus haut en est l’exemple type : l’acheteur n’a pas besoin que le mail soit parti pour que sa commande soit prise. Tout ce dont l’appelant n’attend pas le résultat pour continuer peut basculer en asynchrone. Autre gain, la file absorbe les pics : un afflux la remplit, elle se vide au rythme des consommateurs plutôt que de saturer tout d’un coup et de faire tomber le serveur de mail sous une charge qu’il n’aurait jamais encaissée d’un bloc. Elle sert d’amortisseur.
-
Je laisse en appel direct ce qui attend une réponse. Quand l’appelant a besoin du résultat pour la suite et qu’un seul composant est concerné, la file n’apporte rien. Vous paieriez la traçabilité, l’infrastructure et la latence sans contrepartie. La modernité de l’approche n’entre pas dans la décision. Seul compte le nombre de composants que le fait concerne.
-
Avant d’écrire la moindre publication d’événement, je branche la corrélation. Reconstituer un incident en événementiel suppose de relier les traitements déclenchés par un même fait. Un identifiant de corrélation propagé sur toute la chaîne rend ça possible ; son absence vous condamne à chercher à l’aveugle parmi des logs qui ne savent pas qu’ils racontent la même histoire. Je le pose dès le premier événement. L’ajouter après coup veut dire rejouer du trafic réel pour comprendre ce qui s’est passé.
-
J’écris noir sur blanc la fenêtre d’incohérence. Les réactions étant asynchrones, le système n’est pas cohérent à l’instant T : la facture peut exister une fraction de seconde avant que le stock ne soit décrémenté, et pendant ce court intervalle deux composants donnent du même état une lecture qui ne concorde pas. Personne ne le remarque, dans la plupart des métiers. Encore faut-il l’avoir acté. Sinon vous l’apprenez d’un client qui commande un produit déjà épuisé.
Pour la PME des soldes, ces cinq points tenaient sur une page. Un seul événement publié, un consommateur pour le mail, un identifiant de corrélation dans les logs. Le serveur de mail, lui, n’a pas changé : il prend toujours ses dix secondes aux heures de pointe, sauf que désormais la commande se boucle sans l’attendre et que l’acheteur reçoit sa confirmation un peu plus tard, sans même s’en rendre compte. Plus personne ne les attend.