Idées
RabbitMQ est un facteur, Kafka est un registre
Un broker qui livre puis oublie, un journal qui conserve et laisse relire: on choisit selon ce dont on a besoin après la livraison, pas selon le débit
Quand je forme une équipe à RabbitMQ, je commence par un facteur. Le producteur est l’expéditeur, le message une lettre, l’exchange le centre de tri, la clé de routage l’adresse, la queue la boîte aux lettres. Le binding est le chemin du centre de tri à la boîte: sans binding, la lettre n’est pas routée.
L’analogie dit une chose de plus: une fois la lettre remise, le facteur l’oublie. Quand un consommateur acquitte un message, RabbitMQ l’enregistre comme livré et peut le supprimer. La queue est une salle d’attente, pas une archive. Depuis 2021, RabbitMQ propose aussi des streams, son propre journal, mais ses queues classiques et quorum, celles qu’utilisent la plupart des équipes, fonctionnent toujours ainsi.
Kafka est un registre. Le producteur ajoute des événements à un topic, et ils y restent, lus ou non, aussi longtemps que le prévoit la rétention du topic. Chaque groupe de consommateurs tient sa propre position dans le journal. Un nouveau consommateur peut repartir du début; une fois son bug corrigé, un consommateur peut revenir en arrière et relire.
La question n’est pas lequel est le plus rapide. C’est ce dont on a besoin une fois le message livré
Si la réponse est «rien», parce que le travail est fini quand la commande est traitée ou la notification envoyée, un facteur suffit. Son routage est riche, son modèle simple, et un message important se protège avec des queues durables, des messages persistants, des acquittements manuels et une dead letter queue.
Si la réponse est un historique — une autre équipe qui lira les mêmes événements l’an prochain, un service reconstruit à partir de ce qui s’est passé, un audit — il faut un registre. Et un registre demande une discipline que le facteur n’exige pas: une rétention à dimensionner, des partitions à prévoir, des consommateurs idempotents, puisque relire devient une fonctionnalité.
Le pire choix, c’est le réflexe. Dans un diagnostic d’architecture, j’avais écrit une ligne pour les équipes: Kafka n’est pas un JMS. Utiliser un registre comme un facteur, ou demander au facteur de tenir les archives: voilà comment un bon produit finit accusé d’une mauvaise décision.
On choisit selon ce qui se passe après la livraison