What is RabbitMQ

A message broker — middleware that lets services communicate by passing messages instead of calling each other directly. RabbitMQ implements AMQP 0-9-1: producers publish to exchanges, which route messages into queues, from which consumers receive them. It’s the classic choice for task queues and request-style routing where you need flexible delivery, not a replayable log.

For routing depth see RabbitMQ Exchanges, Queues, DLX, and Quorum Queues; for interview Q&A see RabbitMQ — Common Interview Questions and Answers.

The routing model

The thing that distinguishes RabbitMQ: producers never publish to a queue directly. They publish to an exchange, and bindings decide which queues receive the message.

Producer ──► Exchange ──(binding by routing key)──► Queue ──► Consumer
                  │
                  ├──► Queue B ──► Consumer 2
                  └──► Queue C ──► Consumer 3

Exchange types

Minimal Python example (pika)

import pika

conn = pika.BlockingConnection(pika.ConnectionParameters("localhost"))
ch = conn.channel()
# survives broker restart
ch.queue_declare(queue="tasks", durable=True)

# Producer
ch.basic_publish(
    exchange="",                                       # default direct exchange
    routing_key="tasks",                               # → queue named "tasks"
    body="do work",
    # persistent message
    properties=pika.BasicProperties(delivery_mode=2),
)

# Consumer
def handle(ch, method, props, body):
    process(body)
    # ack AFTER success
    ch.basic_ack(delivery_tag=method.delivery_tag)

# fair dispatch, one at a time
ch.basic_qos(prefetch_count=1)
ch.basic_consume(queue="tasks", on_message_callback=handle)
ch.start_consuming()

Delivery guarantees

RabbitMQ is at-least-once when you use manual acks. The consumer acks only after successfully processing; if it crashes first, the unacked message is requeued and redelivered. That means duplicates happen — consumers must be idempotent.

Durability needs three things together, or you still lose messages:

1. Durable queue (durable=True) — queue survives restart.
2. Persistent messages (delivery_mode=2) — message written to disk.
3. Manual ack — broker keeps the message until the consumer confirms.

Add publisher confirms to know the broker actually accepted a published message. Use a dead-letter exchange (DLX) for messages that fail repeatedly — see RabbitMQ Exchanges, Queues, DLX, and Quorum Queues.

What it’s good for

• Task queues / background jobs — distribute work to a pool of workers (Celery’s default broker — see What is Celery).
• Complex routing — topic/headers exchanges fan one message out by rules.
• Request/reply and per-consumer queues — work that’s consumed once, then gone.
• Smoothing load spikes — the queue buffers bursts.

RabbitMQ vs Kafka

The interview’s favorite comparison. Different tools, not competitors.

Rule of thumb: RabbitMQ when work is consumed once and routing matters; Kafka when you need a replayable event log at high throughput. See What is Kafka.

Common pitfalls

• Forgetting idempotency — at-least-once delivery means duplicates; non-idempotent consumers double-process.
• Auto-ack — acking on delivery (before processing) loses messages on a crash. Ack after success.
• Durable queue but non-persistent messages (or vice versa) — both are required to survive a restart.
• Unbounded prefetch — one greedy consumer grabs thousands of messages; set prefetch_count for fair dispatch.
• No DLX — poison messages requeue forever in a hot loop. Route repeated failures to a dead-letter queue.
• Treating it like Kafka — there’s no replay; once acked, a message is gone.