RabbitMQ vs Kafka: Choosing the Right Message Broker
Fast recall
Quick revision
Core answer
Architectural reasoning — can the candidate pick the right tool for a given problem rather than defaulting to a buzzword.
Saying Kafka is always better because it is more scalable, without acknowledging RabbitMQ's strengths in routing flexibility and lower operational complexity for moderate workloads.
Mention specific scenarios where each shines, discuss the operational cost of each, and note that they can be used together in a hybrid architecture.
Interview-ready guide
Interview answer
RabbitMQ and Kafka solve different problems, and the architectural difference between them drives every trade-off.
- RabbitMQ is a smart broker — it routes messages through exchanges, delivers them to consumers, and deletes them after acknowledgment.
- Kafka is an immutable commit log — it appends messages, retains them for a configurable period, and lets consumers track their own offset.
The decision question:
- Do you need replay? If a new analytics consumer needs to reprocess the last 30 days of events, or you need to rebuild a CQRS projection after a bug, Kafka does that by rewinding the offset — RabbitMQ cannot, because messages are gone after acknowledgment
- If work should disappear once handled — task queues, RPC-over-messaging, order processing — RabbitMQ is simpler and cheaper to operate
When to choose RabbitMQ:
- Complex routing requirements: its exchange-binding model handles exact-key, wildcard, and header-based routing at the broker; Kafka only partitions topics, so complex routing moves into application code
- Sub-millisecond push delivery beats Kafka's poll-based model on latency for time-sensitive task delivery
- A three-node cluster handles moderate workloads without the partition planning and replication math that Kafka requires
When to choose Kafka:
- Event sourcing, analytics pipelines, audit logs, and any scenario where producers and consumers operate at different speeds or where multiple downstream services need independent access to the same events
- Kafka handles millions of events per second and retains data indefinitely by design
I recommend the hybrid approach for mature systems — RabbitMQ for operational commands between services, Kafka for the event backbone feeding analytics and compliance. Choosing Kafka for everything because it "sounds more modern" when your workload is task queues is the anti-pattern to avoid.
RabbitMQ vs Kafka: Choosing the Right Message Broker
Direct Answer
RabbitMQ is a traditional message broker optimized for complex routing, low latency, and task queues where messages are consumed and deleted. Kafka is a distributed event log optimized for high-throughput event streaming with durable replay. Choose RabbitMQ for work queues and flexible routing; choose Kafka for event sourcing, analytics pipelines, and replay requirements.
Code Example
Both deliver messages, but RabbitMQ is a queue (smart broker, dumb consumers — push, ack, route on the broker side) and Kafka is a log (dumb broker, smart consumers — consumers track their own offset and replay anything in the retention window).
// =============== RabbitMQ ===============
@Configuration
class RabbitConfig {
@Bean Queue ordersQueue() { return QueueBuilder.durable("orders").build(); }
@Bean DirectExchange exchange() { return new DirectExchange("orders.exchange"); }
@Bean Binding binding(Queue q, DirectExchange e) {
return BindingBuilder.bind(q).to(e).with("orders.created");
}
}
@Service @RequiredArgsConstructor
class RabbitPublisher {
private final RabbitTemplate template;
public void publish(OrderEvent ev) {
// Routed by exchange + routing key — broker decides where it goes
template.convertAndSend("orders.exchange", "orders.created", ev);
}
}
@RabbitListener(queues = "orders")
public void onOrder(OrderEvent ev) {
process(ev); // ack on return; nack on exception
}
// =============== Kafka ===============
@Service @RequiredArgsConstructor
class KafkaPublisher {
private final KafkaTemplate<String, OrderEvent> template;
public void publish(OrderEvent ev) {
// No exchange — just topic + partitioning key
template.send("orders", ev.orderId().toString(), ev);
}
}
@KafkaListener(topics = "orders", groupId = "fulfilment", concurrency = "4")
public void onOrder(OrderEvent ev, Acknowledgment ack) {
process(ev);
ack.acknowledge(); // consumer commits offset
}
| Aspect | RabbitMQ | Kafka |
|---|---|---|
| Model | smart broker, queues + exchanges | distributed log, topic + partitions |
| Routing | direct, topic, fanout, headers exchanges | partition key only |
| Ordering | per queue | per partition |
| Throughput | ~50k msg/s per node (typical) | millions of msg/s per cluster |
| Replay | no (consumer ack removes message) | yes (offsets, retention window) |
| Consumers | broker pushes; one message → one consumer | consumers pull; many groups can read same topic |
| Multi-consumer fan-out | fanout exchange → multiple queues | many consumer groups on one topic |
| Persistence | optional (durable queues + persistent messages) | always (log on disk) |
| Latency | sub-millisecond | ms-low double-digit |
| Best fit | task queues, RPC, complex routing | event streams, audit logs, replay, analytics |
- RabbitMQ is a great default for task queues and request/response workflows: complex routing rules (work queue, fanout, topic), dead-letter exchanges, priority queues, per-message TTL — all built-in. Reach for it when you want the broker to do work for you.
- Kafka wins for event streams with high throughput and replay: 30-day retention lets a new consumer group reprocess history; one event can be consumed by 10 different services independently; partitions give horizontal scale.
- Ordering: Rabbit preserves order per queue (so one consumer per queue if order matters). Kafka preserves order per partition (key the message to land on the same partition).
- Operationally: RabbitMQ clusters are easier to set up but harder to scale past a few hundred MB/s; Kafka has a steeper learning curve but scales to terabytes/day on the same hardware.
- Many platforms run both: RabbitMQ for task distribution / RPC, Kafka for event sourcing and analytics — they solve different problems.
Common Mistakes & Pitfalls
Saying Kafka is always better because it is more scalable, without acknowledging RabbitMQ's strengths in routing flexibility and lower operational complexity for moderate workloads.
Check your understanding
Answer these without looking back at the article.
- How would you migrate a RabbitMQ-based system to Kafka if replay requirements emerge later?
- Can RabbitMQ simulate Kafka-style replay using streams?
- How does RabbitMQ Streams (introduced in 3.9) change the comparison?
Related interview prep categories
1Want 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.