Le principe
Dans une architecture event-driven (EDA), les composants du système ne s'appellent pas directement. À la place, ils publient des événements — des messages décrivant ce qui s'est passé — et d'autres composants s'y abonnent pour réagir.
C'est un modèle asynchrone et découplé : le producteur d'un événement ne sait pas qui le consomme, ni quand.
Producteur
Producteur
RabbitMQ · Kafka · ActiveMQ
Consommateur
Consommateur
Consommateur
Avantages
- Découplage : les services ne se connaissent pas directement — ajouter un consommateur ne modifie pas le producteur
- Scalabilité : les consommateurs peuvent être multipliés indépendamment pour absorber la charge
- Résilience : si un consommateur est indisponible, les messages s'accumulent dans la queue et sont traités à la reprise
- Traçabilité : les événements constituent un journal naturel des actions du système
Concepts clés
Un fait passé et immuable : "CommandeValidée", "PaiementReçu", "StockMisÀJour". Un événement décrit ce qui s'est passé, pas ce qui doit être fait.
Le service qui émet l'événement. Il publie dans le broker et n'attend pas de réponse. Son travail s'arrête là.
L'intermédiaire qui reçoit, stocke et distribue les messages. Il garantit la livraison même si le consommateur est temporairement indisponible.
Le service qui s'abonne à un type d'événement et réagit. Plusieurs consommateurs peuvent traiter le même événement pour des besoins différents.
Patterns courants
Publish / Subscribe
Un message est diffusé à tous les abonnés. Chacun en reçoit une copie. Adapté pour les notifications, les mises à jour de cache, la synchronisation de données.
Point-to-Point (Queue)
Un message est consommé par un seul consommateur parmi plusieurs. Adapté pour la répartition de charge et les tâches de traitement.
Event Sourcing
L'état du système est reconstitué en rejouant l'historique des événements. Chaque changement est stocké comme un événement immuable — puissant mais complexe.
CQRS
Séparation des modèles de lecture (Query) et d'écriture (Command). Souvent couplé à l'Event-Driven pour synchroniser les deux modèles via des événements.
EDA vs REST synchrone
Service A appelle Service B et attend la réponse. Simple à comprendre, mais si B est lent ou indisponible, A est bloqué. Couplage fort.
Service A publie un événement et continue son traitement. B consomme quand il est prêt. Découplage total, meilleure résilience.
Aller plus loin : RabbitMQ
Pour le détail de l'implémentation avec RabbitMQ (exchanges, queues, bindings, Spring AMQP), voir la page dédiée.
RabbitMQ – Mise en pratique avec SpringBrokers & outils
RabbitMQ Apache Kafka ActiveMQ Spring AMQP Spring Cloud Stream AWS SQS / SNS