RabbitMQ vs Kafka
IntermediateRabbitMQ excels at complex routing, priority queues, and task distribution with message acknowledgement; Kafka excels at high-throughput event log replay and stream processing.
Overview
RabbitMQ and Kafka are both message brokers but solve fundamentally different problems. **RabbitMQ** is a traditional message broker implementing AMQP: it routes messages through exchanges to queues, deletes messages after acknowledgement, and is optimised for flexible routing (direct, topic, fanout, headers), task queues, and RPC patterns. It is the right choice when you need complex routing logic, per-message TTL, priority queues, or request-reply. **Kafka** is an append-only distributed log: messages are retained for a configurable period regardless of consumption, any number of consumer groups can read the same topic independently, and consumers control their own offset. Kafka is optimised for very high throughput, event replay, stream processing (Kafka Streams), and event sourcing. Choosing between them comes down to: **push routing (RabbitMQ) vs pull log (Kafka)**.
Key Architectural Differences
The core difference is the storage model. RabbitMQ is **queue-centric**: messages are stored until consumed and then deleted. Kafka is **log-centric**: messages are stored for a retention period regardless of consumption. Multiple consumer groups can replay the same Kafka log independently; in RabbitMQ, each consumer competes for the same message pool.
// RabbitMQ model — message deleted after ack
Producer → Exchange (routing) → Queue → Consumer (ack → message gone)
→ Consumer2 (same queue = competing consumers)
// Kafka model — message retained in immutable log
Producer → Topic (partition) → Log (offset 0, 1, 2, 3, ...)
↑
Consumer Group A: reads offset 5 (order processing)
Consumer Group B: reads offset 3 (analytics — lags behind, replays)
Consumer Group C: reads from offset 0 (audit replay)
// Key insight: RabbitMQ delivers, Kafka stores; consumers pull from KafkaFeature Comparison
This table captures the decision-relevant differences. Neither broker is universally "better" — they optimise for different workloads.
Feature RabbitMQ Kafka
─────────────────────────── ──────────────────── ────────────────────────────
Storage model Queue (delete on ack) Append-only log (time-based)
Message routing Exchanges + bindings Topic/partition only
Per-message TTL / expiry Yes (x-message-ttl) No (retention is topic-wide)
Priority queues Yes No (manual workaround)
Replay past messages No (deleted after ack) Yes (seek to any offset)
Multiple independent reads No (competing pool) Yes (per consumer group)
Max throughput ~50K msg/s per node Millions of msg/s per node
Ordering guarantee Per-queue FIFO Per-partition FIFO
Built-in stream processing No Kafka Streams / ksqlDB
Dead-lettering Yes (DLX, x-death) Manual (DLT via @RetryableTopic)
RPC / request-reply Yes (built-in) Manual (correlation headers)When to Use Each
Use RabbitMQ for task queues, complex routing, RPC patterns, and workflows that need per-message acknowledgement and visibility into unprocessed messages. Use Kafka for high-throughput event streaming, event sourcing, audit logs, analytics pipelines, and any scenario where consumers need to replay past events independently.
// Choose RabbitMQ when:
// - Task distribution: worker queues processing jobs from a pool
// - Complex routing: route by content type, headers, or routing key wildcards
// - Request-reply: payment service calling pricing service with reply-to queue
// - Per-message TTL or priority: urgent jobs skip ahead of normal jobs
// - Small-medium throughput with strict delivery guarantees
// Choose Kafka when:
// - Event streaming at scale: 1M+ events/sec (user activity, IoT, metrics)
// - Event sourcing: store all domain events and replay to rebuild state
// - Audit log: immutable record that multiple teams can query
// - Stream processing: real-time aggregations with Kafka Streams
// - Multiple independent consumers replay the same event stream
// - Decoupled data pipelines: DB → Kafka → Data Warehouse, ElasticSearch, CacheKey Points to Remember
- 1RabbitMQ: push-based, messages deleted after ack, exchange routing, task queues
- 2Kafka: pull-based, append-only log, message retained regardless of consumption, replay
- 3Multiple Kafka consumer groups read the same topic independently at their own pace
- 4RabbitMQ supports complex routing (topic, headers exchange), priority, TTL, and RPC patterns
- 5Kafka is designed for millions of messages/sec; RabbitMQ peaks at tens of thousands
- 6Use RabbitMQ for routing/tasks; use Kafka for streaming, event sourcing, and audit logs
Interview Questions
Sign in to ask AriaWhat is the fundamental storage model difference between RabbitMQ and Kafka?
Why can multiple Kafka consumer groups read the same topic, but RabbitMQ consumers compete?
In which scenario would you choose RabbitMQ over Kafka for a payment processing system?
Can you replay past messages in RabbitMQ? How would you achieve something similar?
What are the throughput limits of RabbitMQ compared to Kafka and what causes the difference?
Ask Aria about RabbitMQ vs Kafka
Your personal AI tutor — ask anything about this concept
Revision Status
Personal Notes
Sign in to save personal notes for this topic.
Discussion
Sign in to join the discussion.