Event-Driven Architecture : quand et comment l'adopter

Vos systèmes communiquent mal. L’EDA peut changer ça.

Dans une architecture classique, le service A appelle le service B en synchrone. B appelle C. C appelle D. Si D tombe, tout le monde attend. Si le volume triple, tout le monde souffre.

L’Event-Driven Architecture (EDA) renverse ce paradigme. Au lieu de demander, on notifie. Au lieu d’attendre, on réagit. Les systèmes deviennent découplés, résilients et naturellement scalables.

Mais l’EDA n’est pas une solution miracle. Mal implémentée, elle transforme un système complexe en un système complexe et imprévisible.

Comprendre les types d’événements

Tous les événements ne se valent pas. Les confondre est la première erreur.

Domain Events

Un événement domaine représente un fait métier qui s’est produit : CommandeValidée, PaiementReçu, StockMisÀJour. C’est un fait immuable, formulé au passé. Il décrit ce qui s’est passé, pas ce qu’il faut faire.

Ces événements sont au coeur du DDD et reflètent le langage ubiquitaire de votre domaine.

Integration Events

Les événements d’intégration traversent les frontières entre bounded contexts ou systèmes. Ils sont plus stables, versionnés, et leur schéma est contractuel. Un changement de schéma impacte potentiellement plusieurs consommateurs.

Commands

Les commandes ne sont pas des événements au sens strict, mais elles transitent souvent par les mêmes canaux. Une commande exprime une intention : ValiderCommande, EnvoyerNotification. Contrairement à un événement, une commande peut être refusée.

La distinction entre événement et commande est fondamentale. Un événement dit “ceci est arrivé”. Une commande dit “fais ceci”.

Comparatif des technologies de messaging

Le choix du broker de messages conditionne les capacités et les contraintes de votre architecture.

Apache Kafka

Forces : throughput massif (millions de messages/seconde), persistance des messages, replay possible, ordering garanti par partition, écosystème mature (Kafka Streams, Connect, Schema Registry).

Faiblesses : complexité opérationnelle, latence plus élevée que les brokers traditionnels (millisecondes vs microsecondes), courbe d’apprentissage raide.

Cas d’usage : event sourcing, streaming de données, intégration inter-systèmes à haut volume, pipelines de données temps réel.

RabbitMQ

Forces : simplicité de déploiement, routing flexible (exchanges, bindings), support de multiples protocoles (AMQP, MQTT, STOMP), faible latence, patterns avancés (dead letter queues, priority queues).

Faiblesses : pas de replay natif, throughput limité comparé à Kafka, messages supprimés après consommation par défaut.

Cas d’usage : communication inter-services, tâches asynchrones, patterns request/reply, systèmes de notification.

Solutions cloud-native

Amazon EventBridge / Google Pub/Sub / Azure Event Grid offrent des alternatives managées. Zéro infrastructure à gérer, scaling automatique, intégration native avec l’écosystème cloud.

Le compromis : vendor lock-in et moins de contrôle sur le comportement du broker. Pour des systèmes critiques, cette dépendance doit être pesée.

Critères de choix

Event Sourcing : stocker les faits, pas l’état

L’event sourcing pousse la logique événementielle jusqu’au stockage. Au lieu de persister l’état courant d’une entité, on persiste la séquence d’événements qui ont produit cet état.

Le principe

Une commande classique stocke : {statut: "expédiée", montant: 150, adresse: "Paris"}.

L’event sourcing stocke : CommandeCréée -> ArticleAjouté -> PaiementValidé -> CommandeExpédiée. L’état courant est reconstruit en rejouant les événements.

Les avantages

• Audit trail complet — chaque changement est tracé, horodaté et immuable
• Debugging temporel — reconstituez l’état du système à n’importe quel instant passé
• Projection multiple — créez des vues différentes à partir des mêmes événements (reporting, analytics, recherche)
• Correction rétroactive — ajoutez une nouvelle projection qui retraite l’historique complet

Les contraintes

• Complexité de lecture — reconstruire l’état depuis des milliers d’événements prend du temps (les snapshots sont nécessaires)
• Évolution des schémas — un événement est immuable, mais votre domaine évolue (upcasting nécessaire)
• Volume de stockage — les événements s’accumulent indéfiniment

CQRS : séparer lecture et écriture

Le Command Query Responsibility Segregation (CQRS) complète naturellement l’event sourcing en séparant les modèles de lecture et d’écriture.

Pourquoi séparer

Les besoins en lecture et en écriture sont fondamentalement différents. L’écriture valide des règles métier complexes sur un agrégat cohérent. La lecture assemble des données de sources multiples dans des formats optimisés pour l’affichage.

En les séparant, vous pouvez optimiser chaque côté indépendamment : base relationnelle normalisée pour les commandes, Elasticsearch pour la recherche, Redis pour les dashboards temps réel.

Architecture CQRS + Event Sourcing

1. Le command handler valide la commande et émet des événements
2. Les événements sont persistés dans l’event store
3. Des projections consomment les événements et mettent à jour les modèles de lecture
4. Les queries lisent depuis les modèles de lecture optimisés

Cette séparation introduit de la cohérence éventuelle entre écriture et lecture. Un sujet qu’il faut maîtriser.

Le Saga Pattern : transactions distribuées

Dans un système distribué, comment garantir la cohérence d’une opération qui traverse plusieurs services ? Le Saga Pattern apporte une réponse.

Saga par orchestration

Un orchestrateur central coordonne les étapes de la saga. Il envoie des commandes aux services participants et gère les compensations en cas d’échec.

Avantage : logique centralisée, facile à comprendre et à débugger. Inconvénient : l’orchestrateur devient un point de couplage.

Saga par chorégraphie

Chaque service écoute les événements et décide de sa prochaine action. Pas de coordinateur central — la logique est distribuée.

Avantage : découplage maximal, pas de single point of failure. Inconvénient : difficile à suivre, le flux métier est réparti dans plusieurs services.

Compensations

Contrairement aux transactions ACID, une saga ne peut pas faire de rollback atomique. Chaque étape doit avoir une action de compensation : si l’expédition échoue après le paiement, il faut rembourser. Concevez vos compensations dès le départ.

Évolution des schémas d’événements

Votre domaine évolue. Vos événements sont immuables. Comment gérer cette tension ?

Stratégies de versioning

• Weak schema — ajoutez des champs optionnels sans casser les consommateurs existants (le plus simple)
• Upcasting — transformez les anciens événements au format actuel à la lecture
• Schéma versionnée — CommandeCréée_v1, CommandeCréée_v2 avec des handlers distincts

Schema Registry

Un schema registry (comme celui de Confluent pour Kafka) centralise et valide les schémas. Il empêche la publication d’événements incompatibles et documente les contrats entre producteurs et consommateurs.

Cohérence éventuelle : accepter le trade-off

L’EDA implique de la cohérence éventuelle. Après une écriture, il existe une fenêtre pendant laquelle les lectures peuvent retourner des données obsolètes.

Quand c’est acceptable

Un utilisateur qui vient de passer commande et ne la voit pas immédiatement dans son historique. Tolérable ? Probablement, si ça prend moins de 2 secondes.

Quand ça ne l’est pas

Un solde bancaire qui affiche un montant périmé au moment d’autoriser un virement. Pas acceptable.

La cohérence éventuelle n’est pas un bug, c’est un choix architectural qui doit être explicite et validé par le métier.

Quand NE PAS utiliser l’EDA

L’EDA n’est pas la réponse à tout. Évitez-la dans ces situations :

• CRUD simple — si votre application est essentiellement un formulaire au-dessus d’une base de données, l’EDA est du over-engineering
• Transactions ACID strictes — si la cohérence forte est non négociable sur chaque opération, un appel synchrone est plus simple
• Équipe junior — le debugging d’un système événementiel distribué requiert de l’expérience ; ne sous-estimez pas la courbe d’apprentissage
• Prototype ou MVP — la vitesse d’itération prime ; l’EDA ralentit les premières itérations

L’EDA est un outil puissant. Mais un marteau ne transforme pas chaque problème en clou.

Notre approche

Chez Les Artisans du Digital, nous aidons les entreprises à adopter l’architecture événementielle de manière progressive. On ne passe pas d’un monolithe synchrone à un système full event-sourced en une itération.

On commence par identifier les flux métier qui bénéficient le plus du découplage, on met en place un messaging robuste, et on itère. L’EDA est un investissement qui se rentabilise dans la durée.

FAQ

Faut-il toujours utiliser Kafka pour une architecture événementielle ?

Non. Kafka est dimensionné pour des volumes massifs et des cas d’usage nécessitant le replay d’événements. Pour un système traitant quelques milliers de messages par minute avec des besoins simples de communication asynchrone, RabbitMQ ou une solution cloud-native comme Google Pub/Sub sont souvent plus adaptés et moins coûteux à opérer.

Event sourcing et CQRS sont-ils indissociables ?

Non, ce sont deux patterns distincts qui se complètent bien mais peuvent être utilisés séparément. Vous pouvez implémenter CQRS sans event sourcing (modèles de lecture/écriture séparés avec une base relationnelle classique) ou event sourcing sans CQRS (un seul modèle de données reconstruit depuis les événements). En pratique, les combiner offre le maximum de bénéfices.

Comment débugger un système événementiel en production ?

Le tracing distribué est indispensable. Chaque événement doit porter un correlation ID qui permet de reconstituer le parcours complet d’une requête à travers les services. Outillez-vous avec OpenTelemetry, Jaeger ou Tempo pour visualiser les flux. Investissez aussi dans un dead letter queue pour capturer et analyser les événements en échec sans perdre de données.

Quel est le coût de migration vers une architecture événementielle ?

Le coût dépend fortement du point de départ. Pour un monolithe bien structuré, introduire un broker de messages et événementialiser un premier flux métier prend typiquement 4 à 8 semaines pour une équipe de 3-4 développeurs. Le piège est de vouloir tout migrer en même temps. Procédez par flux de valeur, validez en production, puis itérez. Le ROI se mesure en résilience, en capacité de scaling et en vélocité de développement sur le moyen terme.