The short answer
Kafka and RabbitMQ engineers are not interchangeable. Kafka is a partitioned log that retains events after they are read; RabbitMQ routes messages through exchanges to queues and removes them once acknowledged. The operational failure modes differ, so production experience on one transfers partially at best. Hire for the platform you actually run.
Job descriptions routinely ask for “Kafka or RabbitMQ experience”, as if the two were the same skill with different logos. Both are messaging platforms, and an engineer who knows one can learn the other. But they are built on different models, they fail in different ways, and the experience that matters in production — what you do when it breaks — transfers less than the shared vocabulary suggests.
Two different models
Kafka is a partitioned log. A topic is spread across partitions on different brokers, and Kafka guarantees that a consumer reads a given partition's events in exactly the order they were written [1]. Events are not deleted when they are consumed; they are retained for a period set per topic, after which old events are discarded [1].
RabbitMQ routes messages into queues. Messages are published to exchanges, which distribute copies to queues using rules called bindings [2]. The broker removes a message from a queue only once it is acknowledged [2]. For replicated, highly available queues, RabbitMQ's recommended default is the quorum queue, built on the Raft consensus algorithm [3].
Side by side
| Kafka | RabbitMQ | |
|---|---|---|
| Core model | Partitioned log, spread across brokers [1] | Exchanges routing messages to queues [2] |
| After a message is read | Retained until the topic's retention period expires [1] | Removed once acknowledged [2] |
| Replay | Native: consumers re-read the retained log [1] | Through streams, not classic queues [4] |
| What usually breaks first | Consumer lag, uneven partitions, disk sized against retention | Queue depth, memory and disk alarms, quorum loss during node failure |
What transfers, and what does not
- Transfers: the general discipline of running a distributed system in production — capacity planning, watching consumer behaviour, rolling upgrades, and knowing that “did we lose messages” is a question with a precise answer.
- Partly transfers: reasoning about delivery guarantees. Both platforms make you think about acknowledgements and redelivery, but the mechanics differ enough that a confident answer from one platform is often wrong on the other.
- Does not transfer: incident muscle memory. The first ten minutes of a Kafka incident and a RabbitMQ incident involve different metrics, different commands and different wrong instincts. That is precisely the experience a production hire is paying for.
How to tell which one a candidate has actually run
Ask about a specific incident and listen for platform-native detail. A RabbitMQ engineer who has been on call talks about quorum size, partition handling, and what the cluster does when a quorum is lost rather than merely reduced — the same distinctions our DevOps screen tests. A Kafka engineer who has been on call talks about consumer lag, partition assignment and retention against disk. An answer that would fit either platform usually means neither has been run in anger.
When one engineer genuinely covers both
It happens. Platform teams that run both in the same estate do produce engineers with real production depth on each. They are uncommon, and the way to find out is the incident question above, asked once per platform. Where a role genuinely needs both, screen for each platform separately rather than accepting a CV that lists them together.
Sources
- [1] Apache Software Foundation, Apache Kafka: Introduction. Retrieved 4 October 2026.Primary source
- [2] RabbitMQ, AMQP 0-9-1 Model Explained. Retrieved 4 October 2026.Primary source
- [3] RabbitMQ, Quorum Queues. Retrieved 4 October 2026.Primary source
- [4] RabbitMQ, Streams. Retrieved 4 October 2026.Primary source
- [5] Apache Software Foundation, Apache Kafka 4.0.0 Release Announcement. Published 18 March 2025.Primary source
Related questions
Can a RabbitMQ engineer do a Kafka job?
They can learn it, but production experience transfers only partly. Kafka is a retained, partitioned log; RabbitMQ routes messages to queues and removes them once acknowledged. The incident instincts differ, so for a role that will carry Kafka on-call, hire someone who has run Kafka in production.
What is the main difference between Kafka and RabbitMQ?
Kafka stores events in a partitioned log and keeps them after they are read, for a retention period set per topic. RabbitMQ publishes messages to exchanges, which route them to queues, and removes each message once a consumer acknowledges it. RabbitMQ Streams add log-style replay on the RabbitMQ side.