Event-Driven Architecture : systèmes réactifs à grande échelle

Pourquoi l'Event-Driven Architecture

L'architecture événementielle (EDA) est un paradigme où les composants communiquent par émission et consommation d'événements plutôt que par appels directs. Un événement représente un fait qui s'est produit : "CommandeValidée", "PaiementReçu", "StockMisÀJour". Cette approche découple naturellement les producteurs des consommateurs.

Les trois piliers de l'EDA

L'architecture événementielle repose sur trois concepts fondamentaux qui, combinés, permettent de construire des systèmes hautement scalables et résilients.

• Event Notification : un service émet un événement minimal, les consommateurs décident de la réaction
• Event-Carried State Transfer : l'événement contient toutes les données nécessaires, éliminant les callbacks
• Event Sourcing : l'état du système est reconstruit à partir de la séquence d'événements, pas d'une base mutable

CQRS : Command Query Responsibility Segregation

CQRS sépare les opérations d'écriture (Commands) des opérations de lecture (Queries) en deux modèles distincts. Le modèle d'écriture optimise la validation et la cohérence, le modèle de lecture optimise les performances de requêtage. Combiné avec Event Sourcing, CQRS permet de maintenir des vues matérialisées optimisées pour chaque cas d'usage.

                    ┌─────────────┐
   Command ────────►│ Write Model │──── Events ────┐
                    └─────────────┘                │
                                                   ▼
                                           ┌──────────────┐
                    ┌─────────────┐        │ Event Store  │
   Query ──────────►│ Read Model  │◄───────└──────────────┘
                    └─────────────┘
                    (Vue matérialisée
                     optimisée lecture)

Kafka vs RabbitMQ : quel broker choisir

Apache Kafka et RabbitMQ sont les deux brokers les plus utilisés, mais ils répondent à des besoins différents. Kafka est un log distribué optimisé pour le streaming haute performance — il conserve les messages et permet le replay. RabbitMQ est un message broker classique optimisé pour le routage flexible et la consommation garantie.

• Kafka : streaming haute performance, replay d'événements, ordre garanti par partition, idéal pour l'event sourcing
• RabbitMQ : routage flexible (fanout, topic, direct), acknowledgment par message, idéal pour les tâches asynchrones
• Kafka brille à >100K messages/sec, RabbitMQ brille pour le routage complexe avec <10K msg/sec
• Kafka nécessite Zookeeper/KRaft et plus d'ops, RabbitMQ est plus simple à opérer

Pièges et bonnes pratiques

L'EDA introduit de la complexité. L'eventual consistency signifie que les lectures peuvent être temporairement incohérentes. Les événements doivent être idempotents car ils peuvent être délivrés plusieurs fois. Le debugging est plus complexe car le flux est distribué et asynchrone.

• Rendre chaque consumer idempotent — utiliser un ID d'événement unique pour la déduplication
• Versionner les schémas d'événements — utiliser Avro ou Protobuf avec un schema registry
• Implémenter le pattern Outbox pour garantir la cohérence entre DB et broker
• Mettre en place du distributed tracing (Jaeger, Zipkin) pour suivre le flux des événements
• Prévoir des Dead Letter Queues pour les messages non traitables