Kafka vs RabbitMQ : quel outil pour quel besoin ?

Kafka est un log distribué, centré sur le débit, la rétention et l’ordonnancement par partition. Excellente scalabilité horizontale via les partitions et les consumer groups.

RabbitMQ est un broker AMQP orienté routage (exchanges/bindings), acks et patterns de files (work queues, pub/sub). Très flexible côté patterns, priorité, dead-letter, etc.

Schémas mentaux

Avantages clés

- Kafka: très haut débit, stockage persistant scalable, relecture (time travel), ordering par partition, consumer groups parallélisables.

- RabbitMQ: patterns de routage riches (topic, fanout, headers), acks fins, TTL, DLQ, priorités; idéal pour RPC/commandes et orchestration fine.

Quand choisir quoi ?

- Flux d’événements volumineux, analytics, ETL, streaming: Kafka.

- Routage complexe message→file, RPC synchrone, workflows par message: RabbitMQ.

Calculer le nombre de partitions Kafka

Objectifs: parallélisme (1 consumer actif par partition), débit cible, contraintes d’ordre par clé.

Règles pratiques:

- Partitions ≥ nombre maximal de consommateurs concurrents dans un consumer group.

- Si l’ordre est requis par clé (ex: id client), choisir une clé de partitionnement stable pour regrouper les événements d’un même agrégat.

- Dimensionner pour la pointe: P ≈ ceil((events/s × temps_traitement_s) / marge). Exemple: 5 000 ev/s, 50 ms => 250 unités de travail. Avec marge 1.5x, viser ~375 partitions si un seul worker/partition; souvent on vise 48/96/192 et on scale les pods par paliers.

Attention aux "hot keys": une clé très populaire concentrera la charge sur une partition. Solutions: clé composite (ex: clientId + hash mod N), idempotence côté consommateurs, répartiteur "sticky" quand l’ordre n’est pas critique.

Optimiser Kafka (producteur, broker, consommateur)

- Producteur: compression (lz4/zstd), batching (linger.ms=5–20ms, batch.size 32–128KB), acks=all, idempotence activée, retries élevés, limiter max.in.flight.requests (≤ 5 avec idempotence).

- Broker: "num.network.threads", "num.io.threads", taille des segments (log.segment.bytes), politique de rétention (time/bytes), rack awareness, disques rapides (NVMe), OS page cache généreux.

- Consumer: max.poll.records (batch plus gros), fetch.min.bytes / fetch.max.wait.ms (coalescer), session.timeout.ms adapté, commit async contrôlé, backpressure via pause/resume.

- Fiabilité: min.insync.replicas=2 (ou 3) avec acks=all; surveiller ISR. Équilibrer leaders entre brokers; rebalancing stable (cooperative-sticky).

- Schéma: sérialisation compacte (Avro/Protobuf) + registry; éviter payloads très gros (fragmenter ou stocker hors bande).

Optimiser RabbitMQ (si choisi)

- Prefetch (QoS) pour limiter le nombre de messages en vol par consumer et lisser la charge.

- Quorum queues pour durabilité; lazy queues pour gros volumes; observabilité des rates et des acks/nacks.

- Regrouper acks, limiter la taille des messages, connexions/pools stables, éviter fanout excessif non nécessaire.