RabbitMQ is an open source message broker that implements the AMQP 0-9-1 protocol. Producers publish messages to exchanges, exchanges route them into queues through bindings, and the broker deletes each message once a consumer acknowledges it. For a Kafka operator, the important differences are the retention model, broker-side routing, and push delivery.
Architectural model: log vs queue
Kafka stores records in a partitioned, append-only commit log. Records stay on disk for the configured retention window regardless of consumption, the default being 168 hours via log.retention.hours (Apache Kafka broker configuration), and a consumer can rewind its offset and re-read anything still retained. The log structure itself is unpacked in the complete Kafka guide.
The RabbitMQ management UI overview: nodes, connections and message rates.
RabbitMQ’s core data structure is the queue. A message that has been delivered and acknowledged is removed from the queue (AMQP 0-9-1 model). Reads are destructive by design, which is why RabbitMQ has no equivalent of replaying a topic from offset 0.
RabbitMQ does ship a second data structure with log semantics: streams, “a persistent replicated data structure” with non-destructive reads where consumers attach at any point in the log and re-read until retention expires (RabbitMQ streams). A team evaluating RabbitMQ purely from its queue behaviour is looking at half the system.
Log versus queue is the one distinction worth internalising before anything else on this page. In our PagerDuty architecture writeup, the team replaced an AMQP-style broker, Artemis, with an Elixir and Kafka design that routes users to fixed partition sets across topic categories. The reason that redesign was even possible is the log model: partitions gave them a stable, replayable substrate to pin workload to. When teams ask me whether the difference matters in practice, that is the shape of the answer. It is not about features, it is about what your architecture can lean on later.
Routing capabilities
Kafka routing is decided by the producer: a topic name, and optionally a partition key. The broker appends what it receives and applies no routing logic of its own.
RabbitMQ routes inside the broker. A producer publishes to an exchange with a routing key, and bindings decide which queues receive a copy. The four exchange types cover the routing patterns (AMQP 0-9-1 model):
- Direct: exact routing-key match, for unicast delivery.
- Fanout: every bound queue gets a copy, routing key ignored.
- Topic: wildcard pattern match on the routing key, for selective multicast.
- Headers: routing on message attributes rather than the routing key.
The practical consequence for a Kafka team: routing decisions that would need a Kafka Streams job, or a consumer that filters and drops, happen declaratively in RabbitMQ before any consumer runs. How those exchanges, connections and channels behave mechanically is covered in how RabbitMQ works.
Producer-side routing is also where Kafka teams get bitten, so it is worth being honest about the trade. We documented a case from r/dataengineering in our Kafdrop review where a developer watched every message land on a single partition, and the tool gave no hint that the cause was a producer-side key-hashing configuration rather than a broker fault. The lesson carries to this comparison: in Kafka, routing mistakes are made quietly in your own producer code, and your tooling has to be good enough to show you where the keys actually went.
Consumption model
Kafka consumers pull. Each consumer fetches batches at its own pace, and within a consumer group each partition is assigned to exactly one consumer, so partition count caps parallelism.
RabbitMQ pushes. The broker delivers messages to subscribed consumers, and the prefetch (QoS) setting caps how many unacknowledged messages a consumer holds at once. The RabbitMQ documentation recommends the push API over polling, which it describes as “highly inefficient” (AMQP 0-9-1 model). Any number of consumers can compete on one queue, so worker count is not capped by a partition equivalent. The trade is ordering, which competing consumers do not preserve.
Push versus pull is not just an API preference, it shows up on the bill. In our Wix architecture writeup, the team put a push-based fan-out proxy in front of Kafka consumption and cut roughly 30% off their bill, because thousands of polling consumers were doing work the proxy could do once. I read that as the exception that proves the rule. Kafka’s pull model is the right default for throughput, and when a fleet gets big enough that polling itself is the cost, teams end up rebuilding a push layer on top rather than switching brokers.
Scale and throughput vs latency
Kafka’s design optimises for sustained throughput. Sequential disk writes, batching, and consumer-side offset tracking let production deployments run at volumes like DoorDash’s average of roughly 4 million messages per minute, a figure from DoorDash’s own engineering account. Kafka does this best with small messages and degrades with large ones.
RabbitMQ’s per-message state tracking, acknowledgements, and broker-side routing add work per message, which is the structural reason the queue model suits lower-volume workflows where routing and per-message delivery guarantees matter more than raw volume. Published, methodology-backed head-to-head throughput numbers move with version and configuration, so treat any single benchmark figure as a claim to re-verify rather than a property of either system. The criterion-by-criterion decision table lives in the difference between Kafka and RabbitMQ.
Core use cases
Kafka is the standard backbone for event streaming: event sourcing, stream processing with Kafka Streams or Flink, log and metrics aggregation, and change data capture. The unifying property is that many independent consumers read the same durable history at their own pace.
RabbitMQ fits task distribution and service-to-service messaging: background job queues, request-reply between microservices, and workflows that need broker-side routing or per-message TTL. Protocol breadth is also a use case in itself, with AMQP 0-9-1 and 1.0, MQTT, and STOMP supported on their standard ports (RabbitMQ networking).
The two run side by side in many production architectures, streaming on Kafka and task queueing on RabbitMQ. The decision framing across the whole broker family sits on Kafka vs other brokers. Kafka’s share groups, from KIP-932 and explained in Queues for Kafka explained, narrow that gap from the Kafka side on 4.0 or newer.
A sense of what “event backbone” means at the top end: by 2020, 1,500 services at Wix were exchanging events through Kafka. Nobody plans that number up front. It is what happens when the durable-log model works and every new team quietly joins it. My advice to teams choosing between the two is to decide based on the workload in front of them, and to be aware that the Kafka footprint tends to grow into an organisational backbone in a way a task queue rarely does. I walk through the operational side of that growth in my talk, Kafka operational issues and how to survive them.
FAQ
What is RabbitMQ used for?
Task distribution and service-to-service messaging: background job queues, request-reply between microservices, and workflows that need broker-side routing or per-message TTL. Its protocol breadth, AMQP 0-9-1 and 1.0, MQTT, and STOMP, also makes it the integration point for devices and legacy systems that do not speak the Kafka protocol.
Is RabbitMQ push or pull?
Push. The broker delivers messages to subscribed consumers, with the prefetch (QoS) setting capping how many unacknowledged messages a consumer holds. Kafka consumers pull, fetching batches at their own pace.
What are RabbitMQ and Kafka used for?
Kafka is the backbone for event streaming: durable, replayable history read by many independent consumers. RabbitMQ handles task queueing and routed service-to-service messaging. Many production architectures run both side by side.