Message Queues vs Event Streams: RabbitMQ vs Kafka Trade-offs
Fast recall
Quick revision
Core answer
Fundamental difference between push-based queue and pull-based log, ordering guarantees, replay capability, and consumer-group semantics.
Treating Kafka as a 'better RabbitMQ' (it's not — different patterns) or assuming queues can replay messages.
Discuss ordering guarantees per partition vs per queue, exactly-once semantics, retention policies, and modern blurring (RabbitMQ Streams, SQS FIFO).
Interview-ready guide
Interview answer
Two different mental models
Message queue is the post-office model: producer drops a letter, broker delivers to one consumer, consumer processes, broker discards. Per-message state in the broker. Rich routing.
Event stream is the newspaper model: producer appends to an immutable log, the log persists for days/weeks, many consumer groups read independently at their own offsets. Replay any time.
When to use a queue — RabbitMQ, SQS, ActiveMQ
- Task processing: image resize, email sending, video transcoding kickoff
- RPC over messaging with backpressure
- Complex routing: topic exchanges, headers, fanout
- Priorities and scheduled delivery: premium customers first, send in 24h
- Per-message lifecycle: this individual task — ack, redeliver, dead-letter
When to use a stream — Kafka, Pulsar, Kinesis
- Event distribution to many consumers: user.signup → analytics + email + recommendations + CRM, each as separate consumer groups
- Change Data Capture (Debezium → Kafka)
- Event sourcing and audit logs as source of truth
- Analytics pipelines (clickstream → Kafka → Flink → dashboards) with replay if jobs have bugs
- Very high throughput — Kafka does millions of events/sec; RabbitMQ tops out around 50K
- Stream processing (Kafka Streams, Flink, Spark Streaming)
Ordering and delivery
Queue: order preserved per queue with one consumer; lost across multiple parallel consumers. Stream: order preserved per partition. Partition key like user-id keeps all events for one user in order in one partition.
Delivery defaults to at-least-once for both. Exactly-once is achievable with broker support (Kafka transactions) but realistically you make consumers idempotent and accept duplicates.
Backpressure differs:
- Queue: slow consumers grow the queue in broker memory — broker pressure
- Stream: slow consumers fall behind (consumer lag) but broker is unaffected; producers keep producing
Operations
RabbitMQ: mirror queues for HA, watch queue sprawl, memory pressure if consumers fall behind, network partitions need pause-minority policy.
Kafka: partition count = unit of parallelism per consumer group, pick carefully; replication factor 3, min ISR 2; consumer lag is THE metric; disk-heavy because the log is the data.
Cost: Kafka heavier disk + ops, RabbitMQ lighter for low-volume; managed options (MSK, Confluent Cloud, AWS MQ, CloudAMQP) reduce ops burden either way.
Modern blurring
- RabbitMQ Streams: log abstraction inside RabbitMQ
- SQS FIFO + content-based dedup: narrows the gap
- Pulsar: per-subscription mode chooses queue or stream behavior
Decision questions
Do multiple independent consumers need the same data? → Stream Is replay valuable? → Stream Is per-message ack/redeliver/DLQ the value? → Queue ≥ 100K msg/sec? → Stream Need rich routing (topic patterns, headers)? → Queue
Recommendation
RabbitMQ for task queues with rich routing, priorities, scheduled delivery, and per-message lifecycle. Kafka for event distribution where multiple downstream consumers need the same data, for CDC, audit logs, analytics pipelines, and any throughput above 100K msg/sec. They live happily side by side in modern stacks — use both for what each does best, not as substitutes for each other.
Message Queues vs Event Streams: RabbitMQ vs Kafka Trade-offs
Direct Answer
Message queues (RabbitMQ, ActiveMQ, SQS) are designed for task delivery — each message is processed by one consumer and then deleted; the broker tracks state, supports complex routing (topic exchanges, headers), and gives priority/delay/dead-letter queues out of the box. Event streams (Kafka, Pulsar, Kinesis) are designed for event log persistence — messages stay on the log indefinitely, multiple consumer groups read independently at their own offsets, and the log can be replayed. Pick a queue for task processing (image transcoding, sending emails, RPC over messaging). Pick a stream for event distribution (CDC, audit logs, analytics pipelines, multiple consumers needing the same events).
Common Mistakes & Pitfalls
Treating Kafka as a 'better RabbitMQ' (it's not — different patterns) or assuming queues can replay messages.
Check your understanding
Answer these without looking back at the article.
- Walk through how you'd implement exactly-once delivery from Kafka to a database.
- When would Pulsar be a better choice than Kafka or RabbitMQ?
- How do you handle a consumer that's an order of magnitude slower than the producer?
- Design an event-driven order pipeline using Kafka. How many topics, what partitioning?
Related interview prep categories
2Want a guided curriculum order?
These modules are also sequenced in our flagship backend interview track — open it when you prefer an ordered path instead of browsing by topic.