Event-driven : penser en événements

Prérequis : cours 2.3 (Command/Observer) et 4.2.

Pourquoi

« Quand X arrive, faire A, B, C » : l'event-driven découple dans le temps et l'espace (le producteur n'attend pas, ne connaît pas les consommateurs). C'est le ciment des chapitres 5-7 — à condition d'en payer le prix en lucidité.

Concepts

• Événement : fait passé immuable (OrderPlaced { orderId, at, items }, passé composé). Il décrit, n'ordonne pas (vs Command qui demande).
• Bus/topic : le tuyau (Redis Streams, RabbitMQ, Kafka selon l'échelle). Producteurs publient, consommateurs s'abonnent — sans se connaître.
• Ordre et doublons : pas d'ordre global garanti + livraison « au moins une fois » = consommateurs idempotents (clé d'événement dédupliquée) et tolérants au désordre (ou partitionnés par clé).

Exemple : nommer comme une API

// Bon : fait passé, versionné, documenté
{ type: "order.placed.v1", orderId, customerId, total, at }
// Mauvais : "update" générique sans version ni schéma

Cas réel

Notifications envoyées en direct dans checkout() : le SMTP lent fait timeout le paiement. Passage en order.placed + worker : paiement en 200 ms, mails en arrière-plan, retry auto. Le client ne voit plus jamais un timeout SMTP.

Pièges

• Événements sans schéma/version : dans 6 mois personne ne sait ce que contient data. Schéma + version dès le jour 1.
• Chaînes causales invisibles (A émet → B émet → C émet…) : corrélation par ID + observabilité (logs avec eventId), sinon debug impossible.
• Tout en événements, même le synchrone simple : un appel direct suffit quand il faut une réponse immédiate.

À retenir

Faits immuables versionnés, consommateurs idempotents, ordre non garanti, synchrone quand il faut une réponse.