What is RabbitMQ (and how is it different from Kafka)?

RabbitMQ is a mature message broker that implements AMQP — the Advanced Message Queuing Protocol — and it is best understood as a smart broker. A producer hands a message to RabbitMQ, the broker decides where that message should go based on routing rules, delivers it to one or more queues, and deletes it once a consumer acknowledges it. That last detail is the whole story: RabbitMQ is a queue, not a log. Apache Kafka¹, by contrast, is a dumb log — it appends every message to an ordered, durable stream and keeps it around so any consumer can replay history at will. The broker doing the thinking versus the log doing the remembering is the fault line that decides which tool fits which job.

🔗 Learn more — ¹ What is Apache Kafka?

Exchanges, bindings, and queues

In RabbitMQ a producer never publishes directly to a queue. It publishes to an exchange, and the exchange decides which queues receive the message according to bindings — rules that connect an exchange to a queue. The shape of those rules gives you the standard routing patterns.

flowchart TD
    P["Producer — publishes a message"] --> X["Exchange — routes by type + binding"]
    X -->|"routing key = orders"| Q1["Queue: orders"]
    X -->|"routing key = audit.*"| Q2["Queue: audit"]
    X -->|"fanout: all bound"| Q3["Queue: metrics"]
    Q1 --> C1["Consumer A — acks then RabbitMQ deletes"]
    Q2 --> C2["Consumer B"]
    Q3 --> C3["Consumer C"]

A direct exchange routes on an exact routing-key match — send the orders message to the orders queue. A topic exchange matches on wildcard patterns like audit.* or eu.payments.#, so consumers subscribe to slices of a key space. A fanout exchange ignores keys entirely and copies the message to every bound queue, which is how you broadcast. This routing layer is RabbitMQ's defining strength: complex delivery logic lives in the broker, configured declaratively, instead of being hand-coded in producers and consumers.

Acknowledgements and redelivery

Because RabbitMQ deletes messages after they are consumed, it has to know when consumption actually succeeded — so delivery is built on per-message acknowledgement. When a consumer finishes processing, it sends an ack and the broker drops the message. If the consumer crashes, disconnects, or sends a nack before acking, RabbitMQ assumes the work was not done and redelivers the message — to that consumer or another one on the same queue. That gives you at-least-once delivery and automatic failure recovery for free, which is exactly what you want when each message represents a unit of work that must run. Unacknowledged messages that keep failing can be routed to a dead-letter queue for inspection rather than looping forever. None of this requires consumers to track offsets; the queue's state is the source of truth, and it shrinks as work gets done.

When a queue beats a log, and when it loses

A queue wins when messages are tasks to be done once. Distributing work across a pool of workers — image resizing, email sending, order processing — is the canonical fit: competing consumers pull from one queue, each message goes to exactly one worker, and acks guarantee nothing is silently dropped. RPC-style request/reply, where a caller waits for a response correlated back through a reply queue, is a natural RabbitMQ pattern too. And anything needing rich routing — selective fanout, topic subscriptions, priority handling — plays to the smart broker's design.

A log wins when you need replay. If a new consumer must read the entire history from the beginning, or you want to reprocess last week's events after fixing a bug, a queue cannot help — the messages are gone the moment they were acked. Kafka keeps them. A log also wins when many independent consumers each need their own full copy of the same stream and want to track their own position, and when raw throughput dominates: an append-only log on partitioned disk handles firehose volumes that a routing broker maintaining per-message state will not match. This is the territory of stream processing² and event-sourced data pipelines, where the durable, replayable stream is the point.

🔗 Learn more — ² Batch vs stream processing

So RabbitMQ is not really a competitor to Kafka; it is a different tool. Reach for the smart broker when you have work queues, RPC, or complex routing, and reach for the log when you have event streaming and replay. Picking the queue for a replay problem — or the log for a simple task queue — is how teams end up fighting their infrastructure instead of using it.