Topic 10.12
Kafka vs Traditional Queue
In one line
Kafka = replayable log; RabbitMQ = smart router. Both are queues to a product manager and different worlds to you.
Think of it like this
A regular to-do list where a task disappears once someone does it (a simple queue), versus a public noticeboard where the message stays pinned and multiple different teams can each read and act on it independently (Kafka).
Key ideas
- 01
Kafka: distribute the same log to many independent consumers (each replays at its own pace); high throughput; retention-based.
- 02
RabbitMQ: routing, priority, TTL, RPC patterns, per-message ack — a full messaging toolbox.
- 03
Kafka is a log you read multiple times; RabbitMQ is a message DELIVERED once to its consumer queue (per ack).
- 04
Throughput: Kafka fans out to 100 consumers at full speed (disks sequential); RabbitMQ pays per routing work.
- 05
Pick Kafka: event streaming, replay, audit, fan-out to independent pipelines, append-heavy telemetry.
- 06
Pick RabbitMQ: smart routing (topic/header exchanges), RPC, priority queues, small-to-medium traffic.
- 07
Interview: 'the same event feeds billing, analytics, ERP — Kafka lets each consumer own its offset and replay'.
Explain without notes
Why can two downstream services read the same Kafka topic at different speeds — and where RabbitMQ differs?
Practice
For a notification system, choose Kafka vs RabbitMQ for each of: fan-out, retry-with-DLQ, audit replay.
Trade-offs
- ↔
Kafka's model is weaker at per-message routing/priority — RabbitMQ's is weaker at replay and high fan-out.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can justify broker choice from replay/routing/fan-out needs.