RabbitMQ vs Kafka

Two different philosophies

RabbitMQ and Kafka both move messages between services, but they are built on opposite ideas, and the difference decides which one you should use.

RabbitMQ is a smart broker with a dumb consumer. The broker does the hard work — routing, tracking who has acknowledged what, redelivering failures. A message is delivered, acknowledged, and then removed. The consumer just processes and acks.
Kafka is a dumb broker with a smart consumer. The broker is essentially an append-only log: it writes messages to disk and keeps them. It does no routing and forgets nothing on consume. Each consumer tracks its own position (an offset) and can rewind and re-read.

That one difference — remove on ack versus retain and track offsets — cascades into everything else.

flowchart TB
  subgraph rmq["RabbitMQ — queue"]
    m1["msg"] --> qd["deliver"] --> ackd["ack"] --> gone["removed"]
  end
  subgraph kafka["Kafka — log"]
    log["[0][1][2][3][4] retained"]
    ca["consumer A at offset 2"] --> log
    cb["consumer B at offset 4"] --> log
  end

Consume-and-delete queue vs a retained log with offsets

The honest comparison

	RabbitMQ	Kafka
Core model	Queue — deliver then delete	Log — append and retain
Broker role	Smart: routes, tracks acks, redelivers	Simple: stores an ordered log
After consume	Message removed on ack	Message retained; offset advances
Replay	No (it’s gone once acked)	Yes — rewind the offset and re-read
Routing	Rich (direct/topic/fanout/headers)	By partition/topic; logic in consumers
Ordering	Per queue	Strong within a partition
Throughput	High; excels at complex routing	Very high; built for firehose streams
Best at	Task distribution, RPC, complex routing, per-message workflows	Event streaming, replay, analytics pipelines, huge throughput

How to choose

Reach for RabbitMQ when you have discrete units of work to distribute, need rich routing, or want per-message acknowledgement and retry — background jobs, order processing, request/reply. The message is a task that gets done once and disappears.

Reach for Kafka when you have a stream of events that many independent systems consume at their own pace, when you need replay (a new consumer reprocesses history), or when throughput is enormous — event sourcing, activity streams, metrics pipelines. The message is a fact recorded in a log that stays.

And often the right answer is both: Kafka as the durable event backbone, RabbitMQ for task queues and RPC between services. They are not competitors so much as different tools.