The comparison is usually framed as a performance question. It almost never is. Both handle far more traffic than most systems will ever produce, and picking the "faster" one has sunk more projects than picking the slower one ever did.
The real question is what happens to a message after it is consumed.
The one difference everything else follows from
RabbitMQ deletes a message once it has been acknowledged. It is a broker: messages arrive, get routed to queues, get handed to a consumer, and disappear when that consumer confirms it is done. The queue is a holding area.
Kafka keeps everything for a configured retention period, whether or not anyone has read it. It is a log: messages are appended to a partition, and consumers track their own position in it. Reading does not consume. Ten consumers can independently read the same message, and one of them can go back and read last Tuesday again.
Almost every practical difference falls out of this.
What that means when things go wrong
This is where the choice actually bites, and it is worth thinking about before you need it.
Suppose you deploy a consumer with a bug. It reads a million messages and writes garbage.
On Kafka, you fix the bug, reset the consumer group's offset to before the bad deploy, and reprocess. The messages are still there. This is routine.
On RabbitMQ, those messages were acknowledged and deleted. They are gone. Your recovery path is whatever upstream system can regenerate them, if any can.
If you are building anything where "replay it from before the incident" is a plausible recovery plan — event sourcing, analytics pipelines, anything feeding a data warehouse — that single property usually settles it.
What RabbitMQ does that Kafka does not
Kafka's model is deliberately simple, and simplicity costs flexibility. RabbitMQ gives you routing that Kafka has no equivalent for.
Real routing logic. Exchanges let you fan a message out to several queues, route by pattern-matched keys, or send it based on headers. In Kafka, a message goes to a topic and a partition, and consumers filter for themselves.
Per-message acknowledgement and redelivery. A consumer can reject one message and have it requeued or dead-lettered while others proceed. Kafka tracks position in a partition, so one poisoned message at offset 400 blocks everything behind it until you deal with it.
Priority queues, TTLs, delayed delivery. RabbitMQ has these natively. On Kafka you build them yourself, and they fit the model badly.
Competing consumers on one queue. Add consumers to a RabbitMQ queue and throughput rises. Kafka's parallelism is bounded by partition count — a topic with 4 partitions supports 4 consumers in a group, and the fifth sits idle.
Ordering
Both offer ordering guarantees, and both are narrower than people assume.
Kafka guarantees order within a partition. Messages with the same key land on the same partition, so per-key ordering holds. Across partitions there is no global order.
RabbitMQ guarantees order within a queue with a single consumer. Add a second consumer for throughput and ordering is gone.
If you need strict per-entity ordering — all events for one account processed in sequence — Kafka's key-based partitioning gives it to you naturally while still scaling. Getting the same from RabbitMQ means one queue per entity or one consumer, and neither scales well.
Operational cost
This is where teams underestimate the gap.
RabbitMQ is one service. Install it, configure users and vhosts, and it runs. A single node handles a lot, and clustering is well-trodden. Most teams get it working in an afternoon and rarely think about it again.
Kafka is a distributed system that you are now operating. Even with KRaft removing the ZooKeeper dependency, you are managing partitions, replication factors, consumer group rebalancing, retention and disk. Broker disk filling up is a genuine outage class that does not exist with RabbitMQ.
If you do not have someone who wants to own that, use a managed Kafka or use RabbitMQ. A badly-run Kafka cluster is far worse than a well-run RabbitMQ.
Choosing
Use RabbitMQ when you are distributing work to workers — sending emails, resizing images, processing jobs. When routing rules are complex. When each message is handled once and then genuinely finished. When you want one service rather than a cluster. For task queues, it is the better tool and the simpler one.
Use Kafka when several independent consumers need the same stream. When replay matters. When you are feeding analytics or a warehouse alongside real-time processing. When per-key ordering at volume is a requirement. When retention is part of your design rather than an accident.
A useful test: if you removed the queue and replaced it with direct calls, what breaks? If the answer is "nothing much, it would just be slower and less reliable" — that is a task queue, use RabbitMQ. If the answer is "we would lose the record of what happened" — that is an event log, use Kafka.
On running both
Plenty of mature systems do, and it is not a failure of architecture. Kafka carries the event stream that several systems consume and that you might replay; RabbitMQ dispatches the work items that need routing and are done once handled. They solve genuinely different problems, and using each for what it is good at is cheaper than bending one into the other's shape.
What is expensive is choosing on benchmarks. Both are fast. The question is what your messages need to be able to do after someone has read them.
Originally published at https://www.misar.blog/@misar-dev/articles/kafka-vs-rabbitmq-the-one-difference-that-actually-decides-it
