Both move messages between systems, but they solve different problems.
RabbitMQ (classic message broker / queue)
- Messages are typically consumed and removed (or acknowledged and deleted).
- Designed for task queues, work distribution, and complex routing (exchanges, bindings).
- Strong focus on per-message delivery to workers.
- Consumers usually pull work; once acked, that message is gone for that queue.
Kafka (distributed commit log / event streaming platform)
- Messages are appended to a durable log and stay for a retention period.
- Many independent consumers can replay the same data.
- Built for high-throughput event streams, CDC, clickstreams, and decoupling microservices.
- Ordering is per partition; scale comes from partitioning.
RabbitMQ mindset: Kafka mindset: "Do this job" "Record this fact forever (for a while)" producer → queue → worker producer → log → many readers (at their pace)
Side-by-side
| Dimension | Kafka | RabbitMQ | |---|---|---| | Storage model | Append-only log | Queue / broker buffers | | Replay | Native (offsets) | Not the primary model | | Throughput | Very high (partitions) | Good; different sweet spot | | Routing | Topics + keys | Exchanges, routing keys, bindings | | Consumer pace | Independent per group | Often push/pull work items | | Ordering | Per partition | Per queue (with caveats) |
When to choose what
- Kafka: event sourcing-ish streams, analytics pipelines, CDC into a lake/warehouse, many downstream systems reading the same events.
- RabbitMQ: background jobs, RPC-style work, complex routing, "process this once then forget."
Interview tip: Say Kafka is a durable, replayable log; RabbitMQ is a work queue / smart broker. Do not say one is "always better."