Messaging with RabbitMQ
Flexible message routing with a broker and Spring AMQP - queues, exchanges, and when to choose it over Kafka.
On this page
Kafka is a durable event log. RabbitMQ is a traditional message broker built around queues and flexible routing. Both let services communicate asynchronously through a broker, but they're shaped for different jobs - and knowing when to reach for each is the skill. Spring integrates RabbitMQ through Spring AMQP.
Exchanges, queues, and routing
RabbitMQ's model has three moving parts:
- A producer sends a message to an exchange (not directly to a queue).
- The exchange routes the message to one or more queues based on rules (routing keys, patterns).
- Consumers read from queues; once a message is acknowledged, it's removed.
That routing layer is RabbitMQ's strength: fan-out to many queues, route by pattern, priority queues, dead-letter queues for failures - rich, flexible delivery.
@Component
class BorrowConsumer {
@RabbitListener(queues = "borrow.notifications")
void onBorrow(BookBorrowedEvent event) {
// handle the routed message
}
}A newspaper archive (Kafka) keeps every issue forever; anyone can come read the whole run, and new readers start from any date. The postal service (RabbitMQ) routes each letter to specific mailboxes by address and delivers it once; once collected, it's gone. Use the archive when history and replay matter to many readers; use the post when you need smart routing of individual messages to specific handlers.
Kafka or RabbitMQ?
| Reach for… | When you need… |
|---|---|
| Kafka | High-throughput event streaming, durable/replayable history, many independent consumers |
| RabbitMQ | Flexible per-message routing, work queues, request/reply, complex delivery rules |
Neither is "better" - they're different tools. Event sourcing and analytics pipelines lean Kafka; task distribution and intricate routing lean RabbitMQ.
Spring makes them look alike
Spring for Kafka (@KafkaListener) and Spring AMQP (@RabbitListener) present a very similar
programming model - send with a template, consume with an annotated listener. So the choice is
about the broker's delivery semantics (log vs routed queues), not the Spring code, which
stays familiar either way.
For each, choose Kafka or RabbitMQ: (1) an event stream many teams consume for analytics, replaying months of history; (2) distributing image-processing tasks to a pool of workers, one worker per task; (3) routing a message to different handlers based on a routing key pattern.
What is RabbitMQ's defining strength compared with Kafka?
Key takeaways
- RabbitMQ is a traditional broker built on exchanges, queues, and flexible routing; Spring AMQP integrates it.
- A producer sends to an exchange, which routes to queues by rules; consumers read and acknowledge, removing the message.
- Kafka suits durable, replayable, high-throughput streaming for many consumers; RabbitMQ suits flexible routing and work queues.
- Spring's @KafkaListener and @RabbitListener look alike, so the decision is about broker semantics, not code.
- Choose the broker by delivery needs: replayable log (Kafka) vs routed, one-time delivery (RabbitMQ).