Streaming d’Événements en 2026 : Compromis d’Architecture Apache Kafka vs RabbitMQ

1. Queue de messages vs Journal d’événements immuable

RabbitMQ est un système smart broker, dumb consumer construit autour de queues : un message est routé par le broker (via des exchanges et des bindings) vers une ou plusieurs queues, livré à un consommateur, et une fois acquitté, il disparaît — supprimé de la queue. Le broker suit activement l’état par message (non acquitté, prêt, livré à quel consommateur) et effectue le travail de décision de routage, d’ordonnancement par priorité et de redélivrance sur nack. Cela rend RabbitMQ expressif au niveau du routage mais signifie que le cycle de vie d’un message est intrinsèquement lié à sa consommation.

Kafka est l’inverse : un système dumb broker, smart consumer construit autour d’un journal en ajout seul partitionné entre brokers. Les producteurs ajoutent des enregistrements à la fin d’une partition ; le broker ne fait aucune comptabilité par consommateur au-delà d’exposer le journal. Les consommateurs suivent eux-mêmes leur position (offset) dans chaque partition, et un message n’est pas supprimé à la consommation — il reste simplement dans le journal jusqu’à ce qu’une politique de rétention configurée (basée sur le temps ou la taille) le supprime, que quelqu’un l’ait lu ou non. Plusieurs groupes de consommateurs indépendants peuvent lire exactement les mêmes données à des offsets complètement différents, simultanément.

Cette seule différence architecturale est à la racine de presque tous les autres arbitrages entre les deux systèmes. La comptabilité par message côté broker de RabbitMQ vous offre un routage sophistiqué et des garanties de livraison par consommateur, au prix d’un message éphémère. Le journal bête et en ajout seul de Kafka vous offre le rejeu et le fan-out multi-groupes de consommateurs quasiment gratuitement, au prix d’une logique de routage qui doit vivre côté consommateur plutôt que côté broker.

2. Rejeu et Event Sourcing avec Kafka

Comme Kafka conserve les enregistrements indépendamment de leur consommation, un nouveau groupe de consommateurs peut s’attacher à un topic et lire depuis le début de la fenêtre conservée, reconstruisant l’état dont il a besoin à partir de l’historique complet des événements. C’est ce qui fait de Kafka le choix naturel pour l’event sourcing : votre topic est la source de vérité durable, ordonnée et rejouable pour tout ce qui est arrivé à un agrégat, et n’importe quel service — y compris ceux qui n’existaient pas encore au moment où les événements ont été produits — peut construire sa propre vue matérialisée en rejouant depuis l’offset zéro.

L’ordonnancement dans Kafka n’est garanti qu’au sein d’une partition, pas sur l’ensemble d’un topic, ce qui explique pourquoi le choix de la clé de partitionnement est la décision de conception la plus lourde de conséquences dans un système basé sur Kafka : tous les événements pour une entité donnée (un id de commande, un id d’utilisateur) doivent atterrir sur la même partition pour préserver leur ordre relatif, ce qui signifie une clé sur cet id d’entité, pas une distribution round-robin ou aléatoire, dès que l’ordre compte pour le flux d’événements de cette entité.