RabbitMQ interview questions and answers

"We lost about four thousand messages when the broker restarted," the candidate admitted. The interviewer asked whether the queue was durable. It was. "And the messages?" Long pause. A durable queue survives a restart. The messages inside it only survive if they were also published as persistent — two separate settings that everyone assumes are one.

RabbitMQ interview questions concentrate on exactly these seams, because message brokers fail in ways that are invisible until they are expensive. This guide covers exchanges and routing, acknowledgements, durability, dead letter queues, and the RabbitMQ-versus-Kafka question you will definitely be asked.

What RabbitMQ interviews actually test

RabbitMQ interview questions appear in backend, platform and microservices loops. Five bands:

• The routing model — exchanges, bindings, routing keys, and the four exchange types.
• Delivery guarantees — acknowledgements, prefetch, redelivery, at-least-once semantics.
• Durability — the three-part answer that catches most candidates.
• Failure handling — dead letter queues, retries, poison messages.
• Comparison — RabbitMQ vs Kafka, asked in essentially every loop.

Exchanges, bindings and routing

The foundational question is "how does a message get from a producer to a queue?" and the answer people miss is that producers never publish to queues — they publish to an exchange, which routes to queues according to bindings. Getting that sentence right immediately signals you have used it.

The four exchange types:

• Direct — routes to queues whose binding key exactly matches the routing key. Point-to-point work distribution.
• Fanout — copies to every bound queue, ignoring the routing key. Broadcast, such as a cache-invalidation event several services need.
• Topic — pattern matching on dot-separated routing keys, with * matching one word and # matching zero or more. order.*.created versus order.# is a favourite question.
• Headers — routes on header attributes rather than the routing key. Rare, but naming it shows completeness.

Know the default exchange too: a nameless direct exchange to which every queue is automatically bound by its own name, which is why beginner tutorials appear to publish straight to a queue. Explaining that apparent contradiction is a nice signal.

Acknowledgements, prefetch and redelivery

The delivery-guarantee band. By default a consumer should acknowledge explicitly after processing, not on receipt:

• autoAck=true — the broker considers the message delivered the moment it is sent. If your consumer crashes mid-processing, the message is gone. Fire-and-forget only.
• Manual ack after processing — the broker holds the message as unacknowledged; if the consumer dies, it is requeued and redelivered to another consumer. This gives at-least-once delivery.
• Which means consumers must be idempotent — a redelivered message will be processed twice. Say this unprompted; it is the point of the whole section.
• nack / reject — with requeue=true to retry or requeue=false to send it to the dead letter exchange.

A consumer showing all of it together, which is roughly what interviewers want to see written:

import pika, json

channel.queue_declare(
    queue="orders",
    durable=True,                       # queue definition survives restart
    arguments={"x-dead-letter-exchange": "orders.dlx"},
)

# Cap unacked messages so one consumer cannot hoard the queue
channel.basic_qos(prefetch_count=20)

def on_message(ch, method, props, body):
    attempts = (props.headers or {}).get("x-attempts", 0)
    try:
        handle(json.loads(body))          # MUST be idempotent — redelivery is normal
        ch.basic_ack(method.delivery_tag)  # ack AFTER work, never before
    except Exception:
        if attempts >= 5:
            # Stop the poison-message loop: send it to the DLX
            ch.basic_reject(method.delivery_tag, requeue=False)
        else:
            republish_with_delay(body, attempts + 1)
            ch.basic_ack(method.delivery_tag)

channel.basic_consume("orders", on_message, auto_ack=False)

Note that failure does not simply requeue — it either republishes with an incremented attempt count or rejects to the dead letter exchange. That is the difference between a retry policy and an infinite loop.

Prefetch (basic.qos) is the other reliably asked setting: it caps how many unacknowledged messages a consumer may hold. Left unlimited, RabbitMQ pushes everything to whichever consumer connects first, so one consumer is buried while others idle. A prefetch of 1 gives perfect fair distribution with more round trips; a moderate value (10–100) is the usual production compromise. Being able to describe that tradeoff is a strong answer.

Durability: the three-part answer

Back to the four thousand lost messages. Surviving a broker restart needs all three of these, and interviewers ask precisely because candidates name one:

• A durable queue — the queue definition itself survives restart.
• Persistent messages — published with delivery mode 2, so the message body is written to disk. A durable queue full of transient messages is empty after a restart, which is exactly the bug in the story.
• Publisher confirms — otherwise the producer has no idea the broker accepted the message. Publishing into a broker that is down succeeds silently without confirms.

The honest follow-up worth volunteering: persistence costs throughput because it involves disk writes, and even with all three there is a narrow window where a message is accepted but not yet flushed. For stronger guarantees you use publisher confirms with your own retry, or accept the tradeoff explicitly. Also know quorum queues — the modern replicated queue type built on Raft, which replaced classic mirrored queues and is what you should name for high availability.

Dead letter queues and poison messages

A message becomes dead-lettered when it is rejected with requeue=false, exceeds its TTL, or overflows a queue's max length. It is then routed to a dead letter exchange and typically lands in a DLQ for inspection.

The scenario question: a message fails processing every time — what happens? The naive answer, requeue on failure, creates an infinite loop that burns CPU and blocks the queue. This is the poison message problem, and the expected design is:

• Track a retry count in a message header, since RabbitMQ has no built-in delivery counter on classic queues.
• Retry a bounded number of times with a delay — commonly a retry queue with a TTL that dead-letters back to the main queue, which is how delayed retry is implemented without a plugin.
• After N attempts, dead-letter to a DLQ and alert, rather than retrying forever.
• Monitor DLQ depth, because a silently filling DLQ is a failure nobody notices.

Also know the delayed-message exchange plugin as the cleaner alternative for scheduled delivery, and be ready to say why an unbounded retry loop is worse than dropping the message: it can take the whole consumer group down.

RabbitMQ vs Kafka

Asked in nearly every loop, and the wrong move is declaring a winner. The real distinction is architectural:

• RabbitMQ is a message broker — messages are routed to queues and removed once acknowledged. It excels at complex routing, per-message acknowledgement, priorities, and task distribution where each job should be done once.
• Kafka is a distributed log — records are appended to partitions and retained for a configured period regardless of consumption, and consumers track their own offset. It excels at very high throughput, replay, multiple independent consumer groups reading the same stream, and event sourcing.
• Ordering — Kafka guarantees order within a partition; RabbitMQ guarantees order within a queue but concurrent consumers break it in practice.
• Replay — trivial in Kafka by resetting an offset, effectively impossible in RabbitMQ once acknowledged. This is often the deciding factor.

So: background jobs, RPC-style work distribution and complex routing point to RabbitMQ; event streaming, analytics pipelines, replay and very high volume point to Kafka. Plenty of companies run both. Our Kafka interview questions guide covers the other side, and the microservices interview questions guide covers the surrounding architecture.

The docs, a real project, ChatGPT — where each fits

• The official RabbitMQ tutorials — the six-part series covers routing, acks and RPC properly, and is the source of most interview questions.
• The reliability guide in the RabbitMQ docs — the definitive treatment of the durability three-part answer and publisher confirms.
• Running it in Docker and pulling the plug — highest yield here. Publish without persistence, restart the broker, watch the messages vanish. That experiment is the interview.
• The management UI — spend an hour in it. Knowing what unacknowledged versus ready message counts mean is an operational signal candidates rarely have.
• Enterprise Integration Patterns — the vocabulary behind dead letters, competing consumers and routing.
• ChatGPT — good for explaining a concept and generating consumer code. It will not ask whether the messages were persistent as well as the queue durable.
• Greenroom — the spoken layer. Ari, the AI interviewer, runs the round out loud and pushes the failure-mode follow-up your reading never asks. Fair tradeoff: Ari will not restart your broker.

How to prepare for a RabbitMQ interview

• Week 1: routing. Run RabbitMQ locally and build direct, fanout and topic examples; explain the default exchange aloud.
• Week 2: delivery. Kill a consumer mid-processing and watch redelivery, then experiment with prefetch values under load.
• Week 3: durability and failure. Restart the broker with and without persistent messages, then build a bounded retry with a TTL retry queue and a DLQ.
• Final week: rehearse the Kafka comparison without picking a side, prepare one system you built that used a queue, and run two full spoken mocks.

Building the rest of the stack? The Kafka interview questions guide covers streaming, the FastAPI guide covers the service that publishes, the Redis guide covers the other common queue substrate, and the system design guide covers where queues belong in an architecture.

Frequently asked questions

What are the most common RabbitMQ interview questions?

The most common questions cover how a message travels from producer to queue through an exchange and bindings, the four exchange types and when to use each, the difference between automatic and manual acknowledgement and why at-least-once delivery requires idempotent consumers, what prefetch does, the three settings required for messages to survive a broker restart, how dead letter queues handle poison messages, and how RabbitMQ compares with Kafka.

What are the four exchange types in RabbitMQ?

Direct routes to queues whose binding key exactly matches the routing key, suiting point-to-point work distribution. Fanout copies the message to every bound queue and ignores the routing key, suiting broadcasts. Topic performs pattern matching on dot-separated routing keys, where an asterisk matches exactly one word and a hash matches zero or more. Headers routes on message header attributes rather than the routing key and is rarely used.

What is required for RabbitMQ messages to survive a broker restart?

Three things together, and naming only one is the classic mistake. The queue must be declared durable so its definition survives. The messages must be published as persistent with delivery mode 2 so their bodies are written to disk — a durable queue full of transient messages is empty after a restart. And the publisher should use publisher confirms, otherwise it has no idea whether the broker ever accepted the message.

What is prefetch in RabbitMQ and why does it matter?

Prefetch, set through basic.qos, limits how many unacknowledged messages a consumer may hold at once. Without it RabbitMQ pushes messages to whichever consumer is available, so one consumer can be buried with work while others sit idle. A prefetch of 1 gives perfectly fair distribution at the cost of more network round trips, while a moderate value between roughly 10 and 100 is the usual production compromise between fairness and throughput.

How do you handle a message that fails processing every time?

This is the poison message problem, and simply requeuing on failure creates an infinite loop that burns CPU and blocks the queue. The standard design tracks a retry count in a message header, retries a bounded number of times using a retry queue with a TTL that dead-letters back to the main queue for delay, and after N attempts routes the message to a dead letter queue and raises an alert. Monitor dead letter queue depth, since a filling DLQ is otherwise invisible.

What is the difference between RabbitMQ and Kafka?

RabbitMQ is a message broker that routes messages to queues and removes them once acknowledged, excelling at complex routing, per-message acknowledgement and task distribution where each job should be done once. Kafka is a distributed append-only log that retains records for a configured period regardless of consumption, with consumers tracking their own offsets, excelling at high throughput, replay, and multiple independent consumer groups. Replay capability is often the deciding factor.