Overview
Kafka and RabbitMQ both move messages between services, which is where the similarity ends. Kafka is a distributed, partitioned commit log: producers append records, records stay on disk for a configured retention period, and consumers track their own position (offset) in the log, so the same data can be read by many consumers, at different speeds, more than once. RabbitMQ is a message broker in the traditional sense: a smart server that accepts messages, routes them through exchanges to queues based on routing rules, pushes them to consumers, and deletes them once acknowledged.
That difference in model, a log you read from versus a queue that delivers to you, drives almost every practical trade-off between them.
Feature comparison
| Apache Kafka | RabbitMQ | |
|---|---|---|
| Core model | Partitioned, replicated append-only log | Broker with exchanges, bindings, and queues |
| Message lifetime | Retention-based; messages persist whether or not they're consumed | Deleted after acknowledgment (queues); streams add log semantics |
| Replay | Built in; rewind a consumer group to any retained offset | Only with streams; classic/quorum queues can't replay |
| Routing | Minimal; producers pick a topic and partition key | Rich; direct, topic, fanout, and headers exchanges, dead-lettering, TTL, priorities |
| Ordering | Guaranteed within a partition | Guaranteed per queue with a single consumer; weaker with competing consumers or requeues |
| Consumer model | Pull; consumer groups divide partitions | Push with per-consumer prefetch and per-message acknowledgment |
| Throughput posture | Very high; sequential disk I/O, batching, zero-copy | Strong for a broker; streams close much of the gap, classic queues don't |
| Coordination | Self-contained KRaft consensus (ZooKeeper removed in 4.0) | Raft-based quorum queues (classic queue mirroring removed in 4.0) |
| Protocols | Kafka's own binary protocol | AMQP 0-9-1, AMQP 1.0 (core since 4.0), MQTT and STOMP via plugins |
| Ecosystem | Kafka Connect, Kafka Streams, schema registries | Federation, shovel, many client libraries and protocol bridges |
Where Kafka tends to win
Event streaming: when the data itself is the product. Clickstreams, change-data-capture, metrics pipelines, and event sourcing all want what a log provides, high sustained throughput, ordered replayable history, and many independent consumers reading the same events (analytics today, a new service backfilling from history next quarter). Kafka's consumer groups scale horizontally by partition, and its ecosystem (Connect for integrations, Streams for processing) turns it into the backbone of a data platform rather than just a pipe.
Where RabbitMQ tends to win
Task distribution and messaging with real routing needs. Background jobs, RPC-style request/reply, and work queues fit RabbitMQ's per-message acknowledgment, redelivery, priorities, and dead-letter handling naturally, features you'd have to build yourself on Kafka. Its exchange and binding model routes one message to different queues by pattern with no application logic, and it's lighter to operate for modest volumes: a single node is useful, and quorum queues make replication straightforward when you need it. Protocol flexibility (AMQP, MQTT, STOMP) also makes it a good fit for heterogeneous producers like IoT devices.
Note
The two systems keep borrowing each other's strengths: RabbitMQ streams add Kafka-style replayable logs with offset tracking, and Kafka 4.x is adding share groups (KIP-932) for queue-style per-message acknowledgment. The architectural centers of gravity haven't moved, though, pick by your dominant workload, not by the newest feature that papers over the difference.
Verdict
Ask one question first: do consumers need the message history, or just the next task? If events are durable facts that multiple systems will read, replay, and process at their own pace, Kafka's log model is the right foundation. If messages are jobs to be routed, delivered once, acknowledged, and forgotten, with retries, priorities, and dead-letter queues handled for you, RabbitMQ is the simpler, better-shaped tool. Plenty of real architectures run both, RabbitMQ between services, Kafka underneath the data pipeline, because they're solving different problems.