Event Sourcing

Publié par Damien Fleuret le

Temps de lecture : 3 minutes

Event sourcing, une utilisation concrète du Stream processing

Dans un article précédent, nous avons exploré avec vous la notion de Stream Processing. Mais maintenant passons sur une utilisation concrète de ce paradigme, l’Event Sourcing.

« L’Event Sourcing est un pattern d’architecture qui propose de se concentrer sur la séquence de changements d’état d’une application qui a amené cette dernière dans l’état où elle se trouve. L’idée n’est plus de savoir où nous sommes mais de garder trace du chemin parcouru pour y arriver. »

Clément HéliouEvent Sourcing,  comprendre les bases d’un système évènementiel

« L’important, ce n’est pas la destination, c’est le voyage. »  Robert Louis Stevenson

Petite description

L’Event Sourcing est un pattern d’architecture logiciel. Un pattern d’architecture est une idée répondant à une problématique dans un contexte particulier qui est réutilisable dans la plupart des autres cas avec la même problématique.


En informatique, les patterns ont aussi l’avantage d’être « indépendant » du langage de programmation, donc théoriquement applicable dans n’importe quel système d’information.

Il s’agit surtout d’une autre manière de penser, presque à l’opposé de la manière de faire des développeurs. Les données, les états d’un système ne sont plus définis par une somme de paramètres à un instant T mais par une somme d’événements modifiant une situation initiale d’un instant T jusqu’au moment T+1.

Il existe aujourd’hui d’autres patterns impliquant l’utilisation d’événements comme le DP Event NotificationEvent Carried State Transfer.

Voici quelques exemples d’Event Sourcing de notre vie quotidienne :

Exemple 1 : Quand nous rencontrons un ami, on évoque naturellement les nouvelles expériences qui nous sont arrivées depuis la dernière fois que nous l’avons croisé.

Exemple 2 : Concernant le solde d’un compte bancaire, seul les mouvements et le solde original sont importants pour déterminer le solde actuel. Les banques ne s’amusent pas à stocker l’état ( i.e le solde d’un compte) après chaque transaction.

Donc, le plus important en Event Sourcing, c’est de pouvoir construire l’état actuel de notre système à partir de la séquence de changements d’état qui ont eu lieu sur le système, à partir d’un état initial.

Event sourcing appliqué au compte bancaire

Nous sommes restés un peu dans l’abstrait jusqu’à maintenant mais développons plus précisément l’exemple du solde bancaire.

Au début de la journée, John a 20€ sur son compte. Il s’agit de notre situation initiale. Cette donnée est figée et ne change pas au cous de la même journée.

Tout au long de la journée, John va donner de l’argent, acheter des petites choses avec sa carte bancaire et recevoir de l’argent par virement. Il s’agit ici des divers événements qui vont venir impacter le solde de son compte.

Situation initiale (au début de journée)Événements de la journéeSituation après chaque opération
Solde = +20 €Achat Bonbons :  -2€
Donner de l’argent à un ami : -5€
Achat déjeuner : -8€
Argent de poche maman : +10 €
Solde ( 20 – 2 ) = + 18 €
Solde ( 20 – 2 – 5 ) = + 13 €
Solde ( 20 – 2 – 5 – 8 ) = + 5 €
Solde ( 20 – 2 – 5 – 8 + 10 ) = +15 €

Avec cet exemple, on se rend compte que le solde est recalculé après chaque opération. Les soldes intermédiaires ne sont pas stockés. Par contre le solde de fin de journée deviendra la situation initiale de la journée suivante.

Avantages et inconvénients

L’Event Sourcing tire ses avantages et inconvénients du stream processing.
Cependant, il possède quelques avantages spécifiques :

  • La sommes des événements donnera souvent plus d’informations que l’état final d’un système. En effet, les événements représentent l’évolution d’un système dans le temps. La notion d’évolution permet de prédire le comportement de notre système.
  • En cas de de reprise de données (rollbacks ou modifications), il est plus facile de reconstruire l’état de notre système. En effet, à n’importe quel moment, à partir des événements et de la situation initiale, on peut le reconstruire ( un panier d’achat / l’état d’une entreprise,…) .
  • Le schéma de données métier est plus souple  qu’avec le modèle relationnel classique. On peut modifier la visualisation des données plus facilement.
  • Amélioration de l’audit, la série d’événements est maintenant une donnée métier à part entière et non plus une somme de lignes, si elles existent, dans un obscur fichier de logs.

Ainsi que son lot d’inconvénients :

  • Le stockage d’un grand nombre événements peut devenir un problème. L’espace mémoire utilisé est plus important que pour une application plus classique.
  • Le temps d’accès aux données peut devenir très long à mesure que le nombre d’événements s’accroît.
  • Les processus de traitement sont plus abstraits, et nécessitent une documentation plus rigoureuse.

De façon globale, pallier ces inconvénients apporte, le plus souvent, une complexité plus grande que l’irritant initial.

Prenons le problème du stockage. Aujourd’hui, le stockage est relativement bon marché. Mais l’accumulation d’un grand nombre de données peut augmenter sérieusement le temps d’accès aux données.

L’investissement d’une stratégie de snapshot pour réduire sa masse de données sauvegardées est plus coûteuse et augmente la complexité du système d’information.


Cependant, cela peut permettre de ne pas impacter les performances de l’application, voir de les améliorer en gardant les avantages de l’Event Sourcing.

Catégories : Développement

Damien Fleuret

Développeur Back