Event-driven architecture ou Event Sourcing ?

Pareil ? Pas pareil ?

Tout est une question d'échelle, voyez plutôt :

• Une Event-driven architecture (EDA), c'est une modalité de communication entre microservices ;
• L'Event Sourcing (ES), c'est un pattern que l'on retrouve à l'intérieur d'un microservice (ou, plus généralement, d'un contexte au sens du Domain-driven design (1)).

Et rien de plus, fermez le ban 🥁

Non, je vous l'accorde, ça mérite quand-même quelques explications supplémentaires 😁

L'EDA repose sur le fait que de l'information circule sous forme d'événements métiers, caractérisés par un type (par exemple : APPOINTMENT_BOOKED), et généralement accompagnés d'un payload. On peut imaginer ici les identifiants du médecin et du patient #Doctomachin.

La beauté de la chose, c'est le découplage :

• Chaque microservice émet des événements sur un bus de données sans se soucier de qui écoutera (broadcast) ;
• La responsabilité du bus est de délivrer les événements à tous les microservices ayant souscrit à ce type d'événement (généralement au travers d'un "topic"), et rien d'autre. Il n'opère aucune transformation, ne procède à aucun traitement. On parle de "dumb pipes", par opposition aux ETL (Extract, Transform, Load) ;
• Les microservices qui écoutent ces événements, quant à eux, ne savent pas quel service en est à l'origine.

C'est un fonctionnement réactif : chaque microservice procède à des traitements en réaction à des événements du monde extérieur, émettant d'autres signaux en retour.

Ce fonctionnement est tout à fait singulier : il faut bien comprendre que chaque service va accumuler ("sédimenter") de l'information pour pouvoir travailler plus tard, lorsqu'il sera interrogé au travers de son API.

Pourquoi c'est intéressant ? Parce que l'alternative pour un microservice, c'est d'aller chercher l'information quand il en a besoin. Si le microservice qui possède l'information n'est pas disponible, l'appelant ne peut pas travailler. Une EDA favorise donc en particulier l'autonomie des microservices.

On pourrait en dire beaucoup plus sur le sujet, mais le but est de voir en quoi une telle architecture diffère de l'Event Sourcing.

Alors parlons d'Event Sourcing !

Encore une fois, l'ES est un pattern que l'on retrouve à l'intérieur d'un contexte. Il répond à un besoin bien précis : la traçabilité. C'est pour cette raison qu'on le retrouve dans des cas d'école tels que la comptabilité ou le transport maritime (2).

En comptabilité, si l'on a procédé par erreur à un débit de 100€, on ne peut pas simplement supprimer l'écriture correspondante. Le risque de falsification des comptes serait trop grand. Pour cette raison, la seule possibilité est de créer un événement "contraire", à savoir une extourne de 100€.

Ce qui caractérise l'ES, c'est donc une écriture en mode "append only". L'ensemble de ces écritures constitue une "golden source", à comprendre comme la donnée qu'il faut à tout prix protéger et dont tout se déduit. Elle permet la compréhension de l'état présent du système.

Là encore, on pourrait aller beaucoup plus loin, en parlant de fonctions de décision et d'évolution, puis en montrant pourquoi l'ES appelle souvent le CQRS. Mais ce serait trop pour un seul article, alors… ce sera pour une prochaine fois !

(1) Un contexte peut être déployé au sein d'un monolithe modulaire ou en tant que microservice.

_(2) Voir à ce sujet l'article de Martin Fowler : https://martinfowler.com/eaaDev/EventSourcing.html._