Quelle file de messages pour quel problème ?
Une antisèche pour décider vite. Le critère n'est pas le broker le plus puissant, mais le besoin réel : routing simple, rejouabilité d'événements, débit, latence ou multi-site.
Pars de RabbitMQ pour du routing classique (tâches, notifications). Passe à Kafka seulement quand tu dois rejouer un flux d'événements ou tenir un débit massif — sinon c'est de la complexité gratuite.
RabbitMQ / broker à messages
Le défaut. Routing riche, simple à opérer.
Choisir si : files de tâches, notifications, routing complexe (exchanges, topics, priorités).
Éviter si : rejouer un historique d'événements, débit très élevé en continu → ce n'est pas son rôle.
Kafka / log distribué
L'événement est le produit.
Choisir si : event sourcing, rejouabilité, débit massif, plusieurs consommateurs indépendants.
Éviter si : petite appli avec peu de trafic → cluster ZooKeeper/KRaft = complexité opérationnelle réelle.
AWS SQS / file managée
Une file, zéro serveur à gérer.
Choisir si : stack AWS, déléguer la gestion du broker, découplage simple entre services.
Éviter si : multi-cloud ou on-premise, besoin de routing avancé — lock-in AWS fort.
NATS / messagerie légère
La latence, avant tout.
Choisir si : microservices, latence très basse, empreinte réduite, request/reply simple.
Éviter si : persistance/rejouabilité poussée sans JetStream, écosystème d'outils moins riche que Kafka.
Pulsar / streaming multi-tenant
Kafka, mais pensé multi-site.
Choisir si : multi-tenant, géo-réplication native, séparation stockage/calcul.
Éviter si : équipe déjà experte Kafka sans besoin multi-site → écosystème et adoption plus restreints.