RabbitMQ is an open source message broker built on the AMQP 0-9-1 model. It routes messages through exchanges into queues and deletes each message once a consumer acknowledges it, which is the opposite retention model to Kafka’s replayable log. Engineers running Kafka in production compare the two when a workload needs broker-side routing, per-message acknowledgement, or protocol support that Kafka does not provide natively.
One thing I would say before you read any comparison table. Most of the broker problems I get called into are not broker bugs. They are misconfigurations, missing observability, or a reasonable decision someone made without full context. That holds whichever product you pick. So read this page as a fit question, not a quality contest, and budget as much attention for how you will observe and operate the thing as for which one you choose.
Core architectural differences
Kafka is a distributed append-only log. Producers write records to partitioned topics, the broker stores them for a configured retention window whether or not anyone has read them, and consumers track their own position with offsets. Broker, partition and offset fundamentals are collected in the complete Kafka guide. The default retention is 7 days: log.retention.hours defaults to 168 (Apache Kafka broker configuration).
RabbitMQ is a traditional message broker. Producers publish to an exchange, the exchange routes each message into one or more queues using bindings and routing keys, and the broker deletes the message from a queue once a consumer acknowledges it (AMQP 0-9-1 model). The system itself, its queue types and its protocol surface are covered in what RabbitMQ is.
The state models follow from that. RabbitMQ is a smart broker: it tracks delivery and acknowledgement state for every message. Kafka moves that bookkeeping to the consumer, which tracks a single offset per partition. A Kafka consumer can rewind to any retained offset and re-read. A RabbitMQ queue consumer cannot, because an acknowledged message is gone.
RabbitMQ added a log-structured data type of its own for replay workloads: streams, an append-only log with non-destructive reads that consumers can re-read from any point until retention expires (RabbitMQ streams).
The retention model is where this difference stops being academic. We studied DoorDash’s engineering writeups for our Kafka architecture series, and their move is the pattern I see most often: they first adopted Kafka in mid-2019 after repeated RabbitMQ failures started causing order checkout and dispatch outages under peak load. The lesson I take from cases like that is not that RabbitMQ was the wrong product. It is that a delete-on-acknowledge broker gives you nothing to replay when downstream processing breaks, and at a certain scale the ability to rewind becomes the feature you cannot live without.
Specific use cases
Protocol support is the clearest dividing line. RabbitMQ speaks AMQP 0-9-1 and AMQP 1.0 on port 5672, MQTT on 1883, and STOMP on 61613, with TLS variants of each (RabbitMQ networking). Kafka clients speak the Kafka wire protocol only. A fleet of IoT devices publishing MQTT, or a legacy system that already speaks AMQP, connects to RabbitMQ without a bridge.
Routing is the second one. A RabbitMQ topic exchange routes on wildcard patterns, a headers exchange routes on message attributes, and a fanout exchange copies every message to every bound queue. All of that happens inside the broker, before a consumer sees anything. Kafka routing is a producer-side decision: pick a topic, and optionally a partition key. Selective delivery beyond that means a stream processing layer or a consumer that filters and drops.
Transient and time-bounded work also fits the queue model. RabbitMQ supports a TTL per queue via the x-message-ttl argument and a TTL per message via the expiration property, with the lower value winning (RabbitMQ TTL). Kafka retention is per topic, not per message.
Kafka’s own answer to queue semantics is share groups, defined in KIP-932 and covered in Queues for Kafka explained: per-record acknowledgement and more consumers than partitions, on Kafka 4.0 or newer. Kafka has no native dead letter queue primitive outside Kafka Connect, so dead-lettering is a consumer-side convention (dead letter queues in Kafka). The mechanics on the queue side are covered in how RabbitMQ works, and the criterion-by-criterion comparison in the difference between Kafka and RabbitMQ.
My rule of thumb on workload fit, the one I give in my talk Kafka operational issues and how to survive them: Kafka handles millions of small messages a second extremely well, and handles large messages poorly. That single sentence resolves most of the use-case arguments I sit in on. The scale ceiling is real, and DoorDash is a useful reference point for it: five clusters, more than 2,500 topics, around six billion messages a day on average. A queue broker is not the tool for that shape of workload, and equally, Kafka is not the tool for a workload of large, slow, individually precious messages.
Operational trade-offs
For a simple queueing workload, a single RabbitMQ node or a small cluster is less infrastructure than a Kafka deployment with its controller quorum. The comparison narrows as durability requirements grow: replicated RabbitMQ means quorum queues, which run the Raft consensus protocol with a default group size of three members, one per cluster node, and require a quorum of members online to accept work (RabbitMQ quorum queues). Classic queue mirroring, the older replication mechanism, was removed in RabbitMQ 4.0.
Concurrency scales differently in each system. Kafka assigns each partition to exactly one consumer in a consumer group, so parallelism is capped by partition count and adding a partition is a topology change. RabbitMQ runs the competing-consumers pattern natively: any number of workers pull from one queue, and the prefetch setting bounds how many unacknowledged messages each worker holds. The cost is ordering. Kafka guarantees order within a partition. A RabbitMQ queue with multiple competing consumers processes messages concurrently, so end-to-end ordering is not preserved.
Whether you run either topology yourself or buy it as a service is its own decision, with its own cost model, covered in managed vs self-managed data infrastructure.
On the operational side I will add one opinion that applies whichever broker you land on. Fewer clusters is generally better than more. Teams accumulate brokers and clusters the way they accumulate repositories, and every extra one is patching, monitoring, upgrades and a place for configuration to drift. When I compare operational cost between Kafka and a queue broker, I compare the topology each one will actually grow into at my message volumes, not the single-node install either one starts as.
FAQ
What are Kafka and RabbitMQ?
Kafka is a distributed append-only log: producers write records to partitioned topics, the broker retains them for a configured window, and consumers track their own offsets. RabbitMQ is a message broker on the AMQP 0-9-1 model: exchanges route messages into queues, and the broker deletes each message once a consumer acknowledges it.
Is Kafka a queuing system?
No. Kafka is a replayable log, not a delete-on-acknowledge queue. Share groups, defined in KIP-932 for Kafka 4.0 and newer, add queue-style semantics: per-record acknowledgement and more consumers than partitions.
What are the main competitors of Apache Kafka?
For queueing workloads, RabbitMQ is the most common comparison, alongside cloud queues with capped processing windows. For streaming workloads, the alternatives are Kafka-API-compatible engines and managed Kafka services, compared in cloud brokers and Kafka-compatible engines.