RabbitMQ
A traditional message broker with rich routing (exchanges, queues, bindings), per-message acknowledgement, and push delivery. Excellent for complex task routing and request/reply. Lower throughput than Kafka; more features.
- Complex routing, request/reply, prioritized task queues.
- When per-message ack and routing matter more than raw throughput.
- High-throughput event streaming (use Kafka).
- When you want a managed queue with no ops (use SQS).
Definition
RabbitMQ implements AMQP: producers publish to exchanges, which route to queues via bindings (routing keys, topics, headers). Consumers ack individual messages; unacked messages are redelivered. Supports priorities, TTLs, and dead-letter exchanges.
Why it exists
Workloads need flexible routing (route by type, priority, fan-out to multiple queues) and reliable per-message ack, not just a log. RabbitMQ models these directly where Kafka makes you build them.
How it works
Exchange types: direct, topic, fanout, headers. Messages route to bound queues. Consumers pull or get pushed; ack on success, nack to requeue or reject to DLX. Quorum queues add replication for HA. Streams add a Kafka-like log.
Scaling limits
Throughput is far below Kafka (tens of thousands, not millions, of msgs/s). Queue sharding and federation add complexity. Large backlogs stress the broker; not designed for long retention/replay.
Cost shape
Self-hosted broker compute + storage. Blow-ups: huge backlogs, many queues, and over-replication with quorum queues.
Alternatives
- Kafka — Far higher throughput and replay, weaker per-message routing.
- SQS — Managed and simple, but limited routing.
Failure modes
- Queue backlog causing memory pressure.
- Poison messages redelivering forever (use DLX + retry count).
- Split-brain in mirrored queues (use quorum queues).