RabbitMQ

RabbitMQ is a broker. Its superpower is in the routing arrows: a message doesn’t go to a queue directly — it goes to an exchange, and the exchange decides which queues it belongs in based on rules you configure.

The model

Producers publish to an exchange (not directly to a queue).
The exchange routes the message to zero, one, or many queues based on its type and the routing key.
Consumers read from queues. Once a consumer acknowledges a message, it’s gone.

Exchange type	Routing logic
`direct`	Exact routing-key match
`topic`	Pattern match on routing key (`order.*.eu`)
`headers`	Match on message headers
`fanout`	Broadcast to every bound queue (pub/sub)

No consumer filters anything. The broker does the routing for you.

When to reach for RabbitMQ

Routing is the interesting part of your problem — different message types go to different worker pools, or the same message needs to fan out conditionally.
Background jobs with different worker pools — image resize / video encode / email send all consuming from their own routed queues.
Workflows where message shape decides destination — header-based or pattern-based routing.
Per-message delivery control matters more than raw throughput — Rabbit gives fine-grained ACK/NACK, priority queues, TTL, dead-letter exchanges.

What it isn’t

Not a log. Once acknowledged, a message is gone. No replay, no offset rewind. If you need that, use kafka.
Not zero-ops. You run the broker (or pay a managed provider — CloudAMQP, AWS MQ, Bitnami). Less operational weight than Kafka, more than sqs.
Not built for million-msg/sec. It can move a lot, but Kafka is built for throughput. Rabbit is built for routing.

Delivery semantics

At-most-once or at-least-once depending on ACK mode. Exactly-once is the same lie everywhere — see delivery-guarantees — build idempotency|idempotent consumers.

DLQ pattern: configure x-dead-letter-exchange on the source queue. See dead-letter-queue.

When NOT to pick RabbitMQ