Event sourcing en Go

Event sourcing en Go : Le guide pour stocker les événements

Parjerome
Tutoriel Go

Event sourcing en Go : Le guide pour stocker les événements

Maîtriser l’Event sourcing en Go est une étape majeure pour tout architecte logiciel souhaitant concevoir des systèmes ne se contentant pas de stocker des données, mais qui capturent leur évolution temporelle. Conçu autour du principe que l’état d’un système est dérivé de la séquence immuable des événements qui lui sont parvenus, le pattern Event Sourcing offre une traçabilité inégalée. Cet article est destiné aux développeurs Go expérimentés, aux architectes de microservices, et à quiconque cherche à dépasser les limites du modèle CRUD traditionnel pour bâtir des applications de niveau entreprise.

Traditionnellement, les bases de données stockent l’état actuel (le ‘snapshot’). Or, dans des domaines comme la finance, la logistique, ou les jeux vidéo, savoir *comment* cet état a été atteint est souvent aussi important que l’état lui-même. L’approche de l’Event Sourcing répond parfaitement à ce besoin en transformant chaque modification de données en un ‘événement’ – un fait passé, immuable et non modifiable. Nous verrons pourquoi cette approche est un atout critique pour l’auditabilité et la reconstruction d’état, et comment Go, avec sa concurrence et ses interfaces claires, est un candidat idéal pour sa mise en œuvre.

Pour explorer ce sujet complexe mais fondamental, nous allons d’abord poser les fondations théoriques, en comprenant ce qu’implique réellement l’Event Sourcing. Ensuite, nous plongerons dans un code Go concret pour mettre en place un store d’événements robuste. Après l’implémentation, nous aborderons les cas d’usage avancés, des modèles critiques comme la gestion financière et l’inventaire complexe. Enfin, nous couvrirons les pièges à éviter et les meilleures pratiques pour garantir que votre architecture basée sur l’Event sourcing en Go soit scalable et maintenable. Préparez-vous à transformer votre vision de la persistance des données !

Event sourcing en Go
Event sourcing en Go — illustration

🛠️ Prérequis

Pour suivre ce tutoriel approfondi sur l’Event sourcing en Go, un certain socle de connaissances et d’outils est nécessaire. Ne vous inquiétez pas, nous allons détailler chaque point.

Connaissances et outils recommandés

Assurez-vous de maîtriser les concepts de base de Go, notamment les interfaces, la gestion des erreurs, et les structs. Il est fortement conseillé d’avoir une compréhension de base des systèmes distribués, des mécanismes de consensus (type Raft, bien que non requis pour le code, c’est contextuel), et de la modélisation événementielle.

  • Langage Go : Version 1.20 ou supérieure. Ces versions bénéficient des dernières optimisations de la goroutine et du système de types.
  • Outils : Git pour le contrôle de version.
  • Bases de données : Une expérience avec PostgreSQL est fortement recommandée, car nous utiliserons des transactions ACID et potentiellement l’extension JSONB pour stocker les événements.

Pour démarrer, assurez-vous d’avoir installé Go : go install golang.org/x/text/language@latest. Nous utiliserons également des dépendances comme les drivers de base de données Go pour interagir avec le store d’événements.

📚 Comprendre Event sourcing en Go

Le cœur de l’Event sourcing en Go repose sur le principe de l’enregistrement des faits. Plutôt que de stocker l’état (ex: Solde: 100€), on stocke les événements qui ont mené à cet état (ex: Débit: 50€, Crédit: 150€). La reconstruction de l’état est alors une opération de ‘relecture’ des événements dans l’ordre chronologique.

Comment fonctionne l’Event Sourcing ?

Imaginez que vous gérez un compte bancaire. Un système CRUD classique enregistrerait seulement le solde actuel. Si le solde est de 150€, c’est tout. Avec l’Event Sourcing, vous enregistrez : ‘Compte créé avec 0€’, ‘Dépôt de 100€’, ‘Retrait de 20€’, ‘Dépôt de 50€’. L’état actuel est calculé (100 – 20 + 50 = 130€). L’avantage est triple : auditabilité totale, capacité de remonter dans le temps, et séparation claire des préoccupations. Les événements doivent être immuables : ils ne peuvent jamais être changés, seulement ajoutés.

Le rôle de l’Agrégat (Aggregate Root)

Dans un système basé sur l’Event sourcing en Go, l’Agrégat est l’entité métier (ex: CompteUtilisateur) qui est responsable de sa propre logique. Lorsqu’une action arrive (une commande, par exemple : RetirerArgent), elle n’modifie pas directement l’état. Elle vérifie que l’état *perçu* (reconstruit des événements passés) permet cette action, puis elle génère un ou plusieurs événements (ex: RetraitTentativeÉmis). Ces événements sont ensuite persistés dans le ‘Store’.

Nous comparons cela à d’autres approches : alors que les bases de données relationnelles modifient des lignes (approche par valeur), l’Event Sourcing construit des *journaux* de faits (approche par flux). En Go, cela se traduit par des interfaces bien définies qui garantissent que toute opération modifie uniquement la liste d’événements et non l’état interne directement. La structure logique ressemble à ceci :

Client (Commande) -> Agrégat (Validation) -> Événements (Immutables) -> Store (Persistance)

La complexité de la gestion de l’ordre et la nécessité de garantir l’atomicité de l’enregistrement font de Go un choix judicieux grâce à sa gestion native des concurrences et à ses mécanismes de transactions clairs.

Event sourcing en Go
Event sourcing en Go

🐹 Le code — Event sourcing en Go

Go
package main

import (
	"fmt"
	"time"
)

// Event représente un événement métier immuable
type Event struct {
	AggregateID string
	EventType   string
	Timestamp   time.Time
	Payload     map[string]interface{}
}

// EventStore interface définit le contrat pour le stockage d'événements
type EventStore interface {
	SaveEvent(event Event) error
	GetEvents(aggregateID string) ([]Event, error)
}

// InMemoryStore implémente l'EventStore pour les tests et démonstrations
type InMemoryStore struct {
	store map[string][]Event
}

// NewInMemoryStore crée un nouvel EventStore en mémoire
func NewInMemoryStore() *InMemoryStore {
	return &InMemoryStore{
		store: make(map[string][]Event),
	}
}

// SaveEvent persiste l'événement pour un ID d'agrégat donné
func (s *InMemoryStore) SaveEvent(event Event) error {
	s.store[event.AggregateID] = append(s.store[event.AggregateID], event)
	fmt.Printf("Événement enregistré pour %s : %s\n", event.AggregateID, event.EventType)
	return nil
}

// GetEvents récupère tous les événements pour un ID d'agrégat
func (s *InMemoryStore) GetEvents(aggregateID string) ([]Event, error) {
	if events, ok := s.store[aggregateID]; ok {
		return events, nil
	} else {
		return nil, fmt.Errorf("aucun événement trouvé pour l'ID %s", aggregateID)
	}
}

// CompteUtilisateur est l'Aggregate Root
type CompteUtilisateur struct {
	ID string
	Events []Event
}

// NewCompteUtilisateur initialise un nouvel agrégat
func NewCompteUtilisateur(id string) *CompteUtilisateur {
	return &CompteUtilisateur{ID: id}
}

// HandleEvent réapplique un événement à l'agrégat pour reconstruire l'état
func (cu *CompteUtilisateur) HandleEvent(event Event) {
	// Logique de reconstruction de l'état basé sur l'événement
	switch event.EventType {
	case "UtilisateurCréé":
		// Mise à jour de l'état ici...
	case "EmailMisAJour":
		// Mise à jour de l'état ici...
	}
	cu.Events = append(cu.Events, event)
}

func main() {
	// 1. Initialisation du Store
	store := NewInMemoryStore()

	// 2. Création de l'Agrégat
	user := NewCompteUtilisateur("user-42")

	// 3. Événements initiaux
	user.HandleEvent(Event{
		AggregateID: "user-42",
		EventType:   "UtilisateurCréé",
		Timestamp:   time.Now(),
		Payload:     map[string]interface{}{"email": "initial@test.com"},
	})

	// 4. Simulation d'une modification (le nouveau concept !) : Mise à jour de l'email
	newEvent := Event{
		AggregateID: "user-42",
		EventType:   "EmailMisAJour",
		Timestamp:   time.Now().Add(time.Hour),
		Payload:     map[string]interface{}{"nouveauEmail": "nouveau@test.com"},
	}

	// 5. Persistance de l'événement
	err := store.SaveEvent(newEvent)
	if err != nil {
		fmt.Printf("Erreur de sauvegarde : %v\n", err)
	}

	// 6. Reconstitution de l'état après un crash (relecture des événements)
	fmt.Println("\n--- Reconstruction de l'état ---")
	events, err := store.GetEvents("user-42")
	if err != nil {
		fmt.Println("Erreur de lecture :", err)
	} else {
		fmt.Printf("Succès. %d événements lus. L'état est reconstitué.\n", len(events))
	}
}

📖 Explication détaillée

L’objectif principal de ce premier snippet est d’établir le pattern de base de l’Event sourcing en Go : la séparation claire entre le store (la source de vérité) et l’agrégat (la logique métier).

Analyse de l’Architecture de l’Event Store

Nous avons défini une interface EventStore. C’est un choix de design crucial en Go car il garantit que notre logique métier (l’agrégat) dépend d’un contrat (EventStore), et non d’une implémentation concrète (ici, InMemoryStore). Cela permet de basculer facilement vers un PostgresStore ou un CassandraStore sans toucher à la logique de l’agrégat. Dans un environnement réel, cette interface serait implémentée avec des transactions ACID.

Le InMemoryStore sert de mock pour la démonstration. Sa méthode SaveEvent simule l’ajout à un journal de faits pour un AggregateID. Le point clé ici est que nous ne faisons pas de mise à jour (UPDATE) ; nous faisons uniquement de l’ajout (APPEND).

Le Concept d’Agrégat (CompteUtilisateur)

L’agrégat CompteUtilisateur encapsule la logique métier. Il n’a pas de méthode UpdateEmail() qui modifie un champ. Au lieu de cela, il reçoit une Event (comme EmailMisAJour) et utilise la méthode HandleEvent pour répercuter ce fait sur son état interne. L’état de l’utilisateur n’est jamais mis à jour directement ; il est reconstruit en parcourant tous les événements et en appelant des ‘réacteurs’ ou ‘handlers’ pour chaque type d’événement rencontré.

Les pièges potentiels résident souvent dans la gestion des versions. Si le format d’un événement change (par exemple, si nous ajoutons le champ préférence au type UtilisateurCréé), la méthode HandleEvent doit être mise à jour pour gérer cette version, sinon l’état reconstitué sera incomplet ou incorrect. C’est là que le versioning de l’événement (comme l’ajout d’un numéro de version dans la struct Event) devient essentiel. Le design en Go, avec ses interfaces, nous force à cette clarté structurelle, ce qui est un grand avantage par rapport aux langages qui permettent des mutations d’état plus subtiles.

📖 Ressource officielle : Documentation Go — Event sourcing en Go

🔄 Second exemple — Event sourcing en Go

Go
package main

import (
	"fmt"
)

// EventPublisher simule l'envoi d'événements vers un bus de messages (Kafka/RabbitMQ)
type EventPublisher interface {
	Publish(topic string, event []byte) error
}

// KafkaPublisher est un mock pour la publication réelle
type MockKafkaPublisher struct{}

// Publish envoie l'événement à un topic spécifique
func (k *MockKafkaPublisher) Publish(topic string, event []byte) error {
	fmt.Printf("[KAFKA] Événement publié sur le topic '%s': %s\n", topic, string(event))
	return nil
}

// PublishEvents est une fonction qui orchestre la persistance et la publication
func PublishEvents(store EventStore, publisher EventPublisher, aggregateID string, newEvent Event) error {
	// 1. Sauvegarder l'événement de manière transactionnelle (persistance primaire)
	err := store.SaveEvent(newEvent)
	if err != nil {
		return fmt.Errorf("échec de la persistance : %w", err)
	}

	// 2. Publier l'événement pour déclencher des réacteurs (approche CQRS/Microservices)
	// Dans un vrai système, on sérialiserait l'événement en JSON
	eventData := fmt.Sprintf("{...%s...}", newEvent.EventType)
	err = publisher.Publish("user.events", []byte(eventData))
	if err != nil {
		// Gestion de l'échec de publication (rollback ou compensation nécessaire)
		// Idéalement, le store doit être marqué pour un retry.
		fmt.Println("[WARNING] Échec de publication, compensation requise.")
	}
	return nil
}

▶️ Exemple d’utilisation

Imaginons un scénario de gestion de profil utilisateur : un utilisateur change son email et met à jour son profil. Plutôt que de simplement faire un UPDATE user SET email = 'nouveau@test.com', nous allons enregistrer ces changements comme des événements distincts. Le système d’agrégation (le service) va traiter la commande, générer les événements, et s’assurer qu’ils sont enregistrés dans l’Event Store et ensuite publiés.

Scénario : Un utilisateur (ID: U101) vient de se connecter et de changer son email. Nous allons utiliser notre fonction PublishEvents (voir code_source_2).

// Préparation : L'agrégat existe déjà
// Simuler la lecture des événements passés
store := NewInMemoryStore()
user := NewCompteUtilisateur("U101")
// ... (ici, les événements passés sont chargés et l'état est reconstruit) ...

// 1. Création de l'événement de mise à jour
eventUpdate := Event{
AggregateID: "U101",
EventType: "EmailMisAJour",
Timestamp: time.Now().Add(time.Hour),
Payload: map[string]interface{}{"nouveauEmail": "nouveau.pro@example.com"},
}

// 2. Exécution de la persistance et de la publication
err := PublishEvents(store, &MockKafkaPublisher{}, "U101", eventUpdate)

if err != nil {
fmt.Printf("Erreur critique lors de l'enregistrement de l'événement : %v\n", err)
} else {
fmt.Println("Opération réussie. L'état est mis à jour et le système réagit.")
}

La première étape montre que l’événement est d’abord enregistré dans le store (persistance primaire). La deuxième étape, la publication ([KAFKA] Événement publié...), montre que ce fait déclenche des réacteurs externes. C’est ce mécanisme d’écoute passif qui est au cœur de l’architecture Event Sourcing : d’autres services (le service de notification, le service de calcul de score) vont réagir à cet événement pour mettre à jour leurs propres vues, garantissant ainsi l’intégration des systèmes de manière découplée.

[KAFKA] Événement publié sur le topic 'user.events': {...EmailMisAJour...}
Opération réussie. L'état est mis à jour et le système réagit.

🚀 Cas d’usage avancés

L’Event sourcing en Go ne doit pas être vu comme une simple alternative de base de données, mais comme un patron de conception qui transforme la manière dont on pense la persistance. Son véritable pouvoir se révèle dans les cas d’usage complexes où l’audit et la projection de données sont primordiaux. Voici trois scénarios avancés.

1. Gestion des Transactions Financières

Dans ce contexte, chaque mouvement d’argent est un événement (DepositEvent, WithdrawalEvent, FeeChargedEvent). L’état (le solde) n’est qu’une *projection* de ces événements. Cela résout le problème de l’audit car la séquence complète des transactions est garantie.

// Dans le cas d'une transaction bancaire
if balance < withdrawalAmount { return nil, NewInsufficientFundsError("Solde insuffisant") } // L'événement est généré et sérialisé event := Event{...EventType: "WithdrawalAttempt", Payload: {Amount: withdrawalAmount}}

2. Suivi d'Inventaire et de Flux de Produits

Pour les systèmes logistiques, l'inventaire ne change pas arbitrairement. Chaque variation doit être documentée : ProductArrivedEvent, ProductShippedEvent, ProductReturnedEvent. Event Sourcing permet non seulement de savoir combien de produits nous avons, mais aussi *quand* et *d'où* chaque lot est parti. C'est vital pour la gestion des rappels de produits ou des garanties.

// Gestion de la variation de stock
if currentStock < quantityToShip { // Générer un événement de manque de stock event := Event{EventType: "StockShortage", Payload: {Required: quantityToShip, Current: currentStock}} // Persister cet événement permet aux systèmes d'alerte de réagir. }

3. Gamification et Comptes Joueurs (Gaming)

Dans les jeux vidéo, les "points" ou les "ressources" n'augmentent pas simplement. Ils sont le résultat d'actions : KilledEnemyEvent, CompletedQuestEvent, UsedItemEvent. Utiliser Event Sourcing pour les profils de joueurs garantit que si vous devez recréer un état (par exemple, après une mise à jour majeure de l'économie du jeu), vous avez une source de vérité parfaite et complète, car vous réjouez simplement le flux d'actions passées. Ce pattern est souvent combiné avec le CQRS (Command Query Responsibility Segregation) où les événements alimentent des vues optimisées pour la lecture (les 'Read Models').

// Exemple de l'événement de gain de points
event := Event{
AggregateID: "player-id-123",
EventType: "PointsGagnés",
Timestamp: time.Now(),
Payload: map[string]interface{}{"amount": 50},
}
// Le système envoie cet événement à un réacteur qui met à jour la DB de lecture (ex: Redis) avec le score total.

⚠️ Erreurs courantes à éviter

Adopter l'Event sourcing en Go est puissant, mais il comporte des pièges techniques classiques. Ignorer ces points peut rapidement mener à des systèmes difficiles à maintenir ou à des sources de vérité incohérentes.

1. Confusion entre Événement et Commande

Erreur classique : traiter une commande comme un événement. Une Commande (ChangeEmailCommand) est une *intention* d'action. Elle n'est pas un fait passé. Seul l'événement (EmailMisAJourEvent) est un fait passé. L'agrégat doit valider la commande pour *produire* l'événement.

2. Négliger l'Immuabilité

Tenter de modifier un événement après son enregistrement. Par définition, un événement est une preuve historique. Si un événement est incorrect, on ne le modifie pas ; on publie un nouvel événement de correction (EmailMisAJourCorrigeEvent) et on gère la logique métier de la correction lors de la reconstitution de l'état.

3. Mauvaise gestion du Versioning

Si vous changez la structure d'un événement passé (ex: en passant de OldField à NewField), le code de reconstruction de l'état (dans HandleEvent) va paniquer. Il est indispensable de versionner le payload de l'événement pour pouvoir effectuer une migration de données lors de la relecture.

4. Transparence des Transitions

Né pas suffisamment de logique de transition dans l'agrégat. L'agrégat doit ne pas seulement stocker des événements, il doit garantir que la séquence des événements est valide (ex: vous ne pouvez pas passer d'un état 'Désactivé' directement à 'Actif' sans passer par 'En Attente de Validation').

✔️ Bonnes pratiques

Pour écrire un système robuste et évolutif en utilisant l'Event sourcing en Go, l'adhérence aux patterns suivants est cruciale.

1. Adopter le CQRS (Command Query Responsibility Segregation)

Ne pas utiliser le modèle Event Sourcing pour les lectures. Les lectures (Queries) doivent toujours aller vers des vues (Read Models) optimisées, qui sont des tables classiques alimentées par les événements. L'agrégat sert pour les écritures (Commands) uniquement. Cela sépare les responsabilités et optimise les performances de lecture.

2. Garantir l'Atomicité de la Persistance

L'opération de sauvegarde de l'événement (dans le Store) doit être transactionnelle. En Go, cela signifie utiliser les mécanismes de transaction de la base de données (ex: sql.Tx pour PostgreSQL). Si la publication d'événement échoue, la persistance de l'événement doit potentiellement être annulée (rollback).

3. Utiliser des Systèmes de Messagerie Asynchrone

Ne jamais faire de communication synchrone entre services qui réagissent aux événements. Un bus de messages comme Kafka ou RabbitMQ est le choix de facto. L'événement est publié, et les services intéressés (les 'Subscribers') s'abonnent pour réagir, garantissant le découplage (Domain Driven Design).

4. Indexation et Partitionnement des Événements

Dans un store d'événements très volumineux, ne pas charger tous les événements. Les systèmes doivent supporter le partitionnement par AggregateID et permettre de charger uniquement la tranche nécessaire (par exemple, les 100 derniers événements). Ceci est vital pour la performance.

5. Versionnement du Code et des Événements

Maintenez une documentation rigoureuse (et un code!) sur le schéma des événements. Chaque fois qu'un événement est modifié, une migration doit être prévue dans la fonction HandleEvent pour pouvoir rétrograder les anciennes versions des données.

📌 Points clés à retenir

  • Immuabilité : Un événement est un fait passé. Il est gravé dans le marbre et ne doit jamais être modifié.
  • Agrégat Root : Il est l'entité qui supervise la logique et garantit la cohérence au niveau transactionnel.
  • CQRS Séparation des responsabilités : Les écritures (Commands) modifient le journal d'événements ; les lectures (Queries) consultent des vues optimisées (Read Models).
  • Source de vérité : L'intégralité de la séquence d'événements est la seule source de vérité. L'état n'est qu'une projection.
  • Atomicité : La persistance des événements et la publication des événements doivent être traitées comme une seule transaction logique.
  • Reconstruction de l'état : L'état actuel est toujours recalculé en appliquant tous les événements depuis la création de l'agrégat.
  • Découplage : L'utilisation d'un bus de messages (ex: Kafka) garantit que les services réagissent aux événements sans dépendre de la disponibilité immédiate des autres.
  • Auditabilité : Le bénéfice majeur est la capacité de recréer le système à n'importe quel point dans le temps, parfait pour la conformité réglementaire.

✅ Conclusion

En résumé, l'Event sourcing en Go est une méthodologie de conception de systèmes de persistance radicalement différente, passant d'une logique de 'mise à jour de valeur' à une logique de 'journal de faits'. Nous avons vu comment l'utilisation de Go, avec sa robustesse concurrente et ses interfaces explicites, permet d'implémenter ce pattern de manière sûre et performante. Qu'il s'agisse de la modélisation de flux financiers critiques, de la gestion de l'inventaire complexe ou de la traçabilité des interactions utilisateur, l'Event Sourcing garantit une source de vérité parfaite et une auditabilité sans précédent.

Il est crucial de comprendre que cette approche introduit une complexité initiale, mais cette complexité est largement compensée par la robustesse et la flexibilité architecturales qu'elle confère. Pour approfondir vos connaissances, je vous recommande vivement d'étudier des cas concrets comme ceux utilisés par des banques ou des systèmes de jeu à grande échelle. Des ressources comme le livre "Event Sourcing" ou des workshops sur Kafka et le CQRS sont excellents points de départ.

L'adoption de l'Event Sourcing, et l'apprentissage de son implémentation en Go, transforme votre profil de développeur. C'est un savoir-faire de niveau architecte qui ouvre les portes de systèmes distribués de très grande envergure. Rappelez-vous que cette approche n'est pas une solution miracle, mais un outil extrêmement puissant qui nécessite une discipline de modélisation rigoureuse. La communauté Go est incroyablement dynamique et les bibliothèques pour ce domaine ne cessent de croître, notamment autour de la gestion de la sérialisation et des messages asynchrones. Pour les bases théoriques et la référence, n'oubliez pas la documentation Go officielle.

Nous espérons que cet article vous aura fourni les clés pour maîtriser l'Event Sourcing en Go. N'hésitez pas à le mettre en pratique dès aujourd'hui ! Quelle fonctionnalité complexe allez-vous modéliser en premier ? Partagez vos expériences de développement avec les événements !

Publications similaires

2 commentaires

  1. Ping : Opérations atomiques Go : Maîtriser sync/atomic pour la performance - Goia, du Go
  2. Ping : QUIC avec quic-go : Le transport moderne de Go - Goia, du Go

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *