RabbitMQ Administrator — Interview Questions.

RabbitMQ is a traditional message broker implementing AMQP (and MQTT/STOMP) — a smart broker that routes messages to queues and pushes them to consumers, with rich routing, per-message acknowledgement, and (by default) delete-on-consume semantics. Kafka is a durable log where consumers pull and messages are retained for replay. Rule of thumb: RabbitMQ excels at complex routing, task/work queues, request-reply, and per-message delivery control; Kafka excels at high-throughput event streaming, replay, and many independent consumers. RabbitMQ = "smart broker, dumb consumer"; Kafka = "dumb broker, smart consumer."

Producers publish to an exchange, never directly to a queue. The exchange routes the message to one or more queues according to bindings (rules linking exchange→queue) and the message's routing key. Consumers read from queues. This indirection is what gives RabbitMQ flexible routing — you can rewire which queues receive what by changing bindings, without touching producers. A queue holds messages until a consumer acks them.

Direct: routes to queues whose binding key exactly matches the routing key (point-to-point / by category). Fanout: ignores routing key, broadcasts to all bound queues (pub/sub). Topic: pattern-matches routing keys with wildcards (* = one word, # = zero+ words), e.g. logs.error.* (flexible routing by topic hierarchy). Headers: routes on message header attributes instead of routing key. The default (nameless) exchange is a direct exchange where the routing key = queue name, which is why you can "publish to a queue" directly.

An ack tells the broker the consumer finished processing a message so it can be removed from the queue. With manual acks, if a consumer dies before acking, RabbitMQ requeues the message and redelivers it (at-least-once — no loss). With auto-ack, the message is considered delivered the moment it's sent, so a crash loses it (at-most-once). You can nack/reject a message with requeue=true (retry) or false (drop or route to a dead-letter exchange). Always ack after successful processing for reliability.

Three things must all hold: the queue is durable, the message is persistent (delivery mode 2), and ideally the exchange is durable too. A durable queue survives restart; persistent messages are written to disk. Caveat: persistence isn't an absolute guarantee — a message can still be lost in the window before it's flushed to disk unless you use publisher confirms (the broker acks the publisher only once the message is safely persisted/handled). Durable + persistent + publisher confirms is the reliable-publish combo. Quorum queues make this stronger via replication.

An AMQP message broker that routes messages from producers through exchanges to queues, pushing them to consumers with per-message acks and (by default) delete-on-consume.

Where producers publish; it routes messages to queues by type + bindings + routing key (producers never publish directly to queues).

An ordered buffer holding messages until a consumer acknowledges them.

A rule linking an exchange to a queue (with a binding/routing key) that determines which messages reach the queue.

A message attribute the exchange uses (with bindings) to decide routing — e.g. matched exactly (direct) or by pattern (topic).

Direct (exact key), Fanout (broadcast), Topic (wildcard patterns), Headers (match on headers); the default nameless exchange routes by queue name.

A consumer ack tells the broker to remove the message; without ack (crash) it's requeued/redelivered — at-least-once.

Durable queue + persistent message (delivery mode 2) + durable exchange; with publisher confirms to close the pre-flush gap.

A logical namespace (own exchanges/queues/permissions) for multi-tenancy/env isolation within one broker.

Where messages go when rejected/expired/over-length — for inspection or reprocessing instead of infinite requeue.

basic.qos prefetch_count limits how many unacked messages a consumer can hold at once. With no limit, RabbitMQ pushes the whole queue at a fast consumer, blowing its memory and starving other consumers (one greedy consumer hoards everything). Set a sensible prefetch (often start ~10–100, or 1 for slow/long tasks) to get fair dispatch across consumers and bounded memory. Too low underutilizes (consumer idles waiting for the next message round-trip); too high causes uneven load and big redelivery on crash. Tuning prefetch is one of the highest-impact RabbitMQ knobs.

A message goes to a dead-letter exchange (DLX) when it's rejected/nacked with requeue=false, expires (message/queue TTL), or hits a queue max-length. The DLX routes it to a dead-letter queue for inspection or reprocessing — your safety net for poison messages instead of infinite requeue loops. Delayed retry pattern: publish to a "wait" queue with a TTL and no consumer; on expiry the message dead-letters back to the work exchange — giving a delay before retry. (Or use the delayed-message plugin.) Track a retry count in headers and route to a parking/DLQ after N attempts so failures don't loop forever.

Quorum queues are the modern HA queue type — a Raft-replicated log across an odd number of nodes (majority quorum), purpose-built for data safety and predictable failover. Classic mirrored queues (the old HA mechanism via policies) are deprecated/removed — they had known correctness issues during partitions and failovers (split-brain, message loss). For anything needing HA, use quorum queues: durable by design, replicated, survive node loss as long as a majority is up. Trade-offs: quorum queues use more memory/disk and need ≥3 nodes for real fault tolerance, and they're geared to longer-lived, important messages rather than ultra-low-latency transient ones. There's also streams for high-throughput, replayable, Kafka-like workloads.

By default a publish is fire-and-forget — the producer doesn't know if the broker actually got/persisted it. Publisher confirms put the channel in confirm mode: the broker sends an async ack once the message is safely handled (routed + persisted for durable/persistent messages) or a nack if it couldn't. This closes the data-loss window on the publish side — you retry on nack/timeout. Combine with mandatory flag (or alternate exchange) to detect messages that route to no queue (otherwise silently dropped). Confirms are the publish-side equivalent of consumer acks: together they give end-to-end at-least-once.

A cluster is multiple nodes sharing metadata (users, vhosts, exchanges, bindings, queue definitions) so clients can connect to any node. But a classic queue's data lives on one node unless replicated — that's why HA needs quorum queues (replicated) or streams; otherwise losing a node loses its non-replicated queues. Nodes need a stable network and the shared Erlang cookie to form a cluster. A virtual host (vhost) is a logical namespace — its own set of exchanges/queues/permissions — used for multi-tenancy and environment isolation within one broker. Use a load balancer in front for client connections, and put a quorum of nodes (3+) across AZs for HA.

A message that repeatedly fails processing and, if requeued, loops forever — blocking the queue and burning CPU. Handle it with a retry-with-limit pattern: track delivery/retry count (RabbitMQ adds an x-delivery-count on quorum queues, or you maintain it in headers), and after N attempts dead-letter it to a DLQ instead of requeuing. Quorum queues support delivery-limit which auto-dead-letters after a set number of redeliveries — the clean built-in fix. Then alert on DLQ depth and inspect/replay manually. Never blind-requeue on failure; that's how one bad message stalls a whole pipeline.

Limits unacked messages per consumer; without it a fast consumer hoards the queue and starves others — set a sensible prefetch for fair dispatch + bounded memory.

Publish to a wait queue with a TTL and no consumer; on expiry it dead-letters back to the work exchange — a delay before retry; track retry count to cap attempts.

Quorum queues are Raft-replicated, safe, and the modern HA type; classic mirrored queues are deprecated (split-brain/loss issues) — use quorum for HA.

Broker async-acks the publisher once a message is safely handled/persisted (nack if not) — closes the publish-side loss window; pair with mandatory for unroutable detection.

Nodes share metadata so clients connect to any; queue data lives on one node unless replicated (quorum queues/streams), and nodes need the shared Erlang cookie.

A message that always fails and loops if requeued; cap retries (x-delivery-count / delivery-limit on quorum queues) and dead-letter to a DLQ.

Direct for exact-match routing, topic for hierarchical/wildcard routing, fanout for broadcast pub/sub to all bound queues.

Queues that keep messages on disk rather than RAM, bounding memory for large backlogs at some throughput cost — for deep-queue workloads.

A queue is delete-on-consume with per-message routing; a stream is an append-only, replayable log (Kafka-like) for high-throughput, many-reader workloads.

Mandatory returns unroutable messages to the publisher; an alternate exchange catches them instead — otherwise messages routing to no queue are silently dropped.

First understand why, then relieve pressure. (1) Diagnose: are consumers slow, too few, crashing/redelivering (check redelivery rate), or is publish rate genuinely exceeding capacity? Check the management UI for publish vs ack rates and unacked counts. (2) Immediate relief: scale out consumers (up to useful parallelism), tune prefetch so they're not idling, and fix any poison-message requeue loop. (3) Protect the broker: a giant backlog of messages forces RabbitMQ to page to disk and can hit the memory high watermark, which triggers flow control and blocks publishers — so cap with queue max-length/TTL + DLX to shed or divert overflow rather than OOM the node. (4) Structural fix: lazy/quorum queue behavior for big backlogs (keep messages on disk), faster consumers/batching, or reconsider if a streaming log (Kafka/streams) fits better. RabbitMQ is happiest when queues are near-empty — a deep queue is a warning sign, not a feature.

RabbitMQ self-protects against running out of resources. The memory high watermark (default ~40% of RAM) — when broker memory exceeds it, RabbitMQ applies flow control and blocks publishing connections until memory drops (consumers keep draining). The disk free-space limit — if free disk falls below the threshold, publishers are similarly blocked to avoid filling the disk (persistent messages need disk). Flow control also throttles fast publishers internally when downstream (e.g. disk) can't keep up — you'll see connections in flow state. Admin implications: monitor these watermarks, give the node enough RAM/disk headroom, use lazy/quorum queues to keep memory bounded, and treat "publishers blocked" as the broker telling you it's overwhelmed — fix the backlog or capacity, don't just raise the watermark blindly.

A partition splits the cluster so nodes can't see each other — risking split-brain (both sides act independently, diverging). RabbitMQ's response depends on the cluster_partition_handling mode: ignore (you must fix it manually — dangerous), pause_minority (nodes in the minority side pause themselves so only the majority keeps serving — the safe default for 3+ nodes), or autoheal (a winning partition is chosen and losers restart). With quorum queues, Raft handles it correctly — the side with majority keeps accepting writes, the minority can't, so no divergence (this is the main reason to use quorum queues over classic mirrors, which could lose messages on partition). Recovery: restore the network, let minority nodes rejoin and resync, verify queue contents, and investigate the network cause. Design for it: odd node count, pause_minority, quorum queues, and nodes spread across AZs with reliable links.

Close the loss window at every hop. Publish side: durable exchange + durable queue + persistent messages + publisher confirms (retry on nack/timeout) + mandatory (or alternate exchange) so unroutable messages aren't silently dropped. Storage: quorum queues across 3 nodes / AZs so a node loss doesn't lose messages. Consume side: manual acks after successful processing, sensible prefetch, and idempotent consumers (at-least-once means duplicates on redelivery — dedupe by message id). Failure handling: DLX + delivery-limit so poison messages park in a DLQ instead of looping. Operate: monitor confirm/ack rates, queue depth, DLQ depth, and the memory/disk watermarks. Honest caveat: RabbitMQ gives at-least-once, not true exactly-once — idempotency on the consumer is how you make duplicates harmless.

Diagnose (slow/few consumers vs over-publish), scale consumers + tune prefetch, fix poison loops; protect the broker — backlog hits the memory watermark → flow control blocks publishers, so cap with max-length/TTL + DLX or use lazy/quorum queues.

Above the memory high watermark (~40% RAM) or below the disk free limit, RabbitMQ blocks publishing connections until it recovers; flow control also throttles fast publishers when downstream can't keep up.

Durable exchange+queue, persistent messages, publisher confirms + mandatory, quorum queues across 3 nodes, manual acks after success, sensible prefetch, idempotent consumers, DLX + delivery-limit; monitor confirm/ack/queue/DLQ.

Partitioned nodes diverge; set cluster_partition_handling to pause_minority (minority pauses) and use quorum queues (Raft majority keeps writing, minority can't) — avoids divergence.

A Raft-replicated log across an odd number of nodes; a write is committed once a majority persist it, surviving node loss while a majority is up — stronger than classic mirrors.

More consumers + tuned prefetch, multiple queues/sharding to parallelize, lazy queues for big backlogs, faster ack/confirm batching, and adequate node resources; consider streams for very high throughput.

Cluster of odd node count across AZs, quorum queues for replication, pause_minority, an LB in front for client connections, and stable low-latency links between nodes.

Deep queues force paging to disk, raise memory toward the watermark (blocking publishers), and slow delivery; RabbitMQ is a broker, not a long-term log — keep consumers keeping up.

Use shovel/federation to move messages to the new cluster, dual-consume to verify, cut producers over, drain old queues, then switch consumers — confirm counts match.

Unacked messages are redelivered on consumer failure (possibly out of order / with the redelivered flag); design idempotent consumers and use prefetch + single active consumer where strict order matters.

Understand why, then relieve pressure. Diagnose: slow consumers, too few, crashing/redelivering, or publish genuinely exceeding capacity (check publish vs ack rates in the UI). Relief: scale out consumers, tune prefetch so they're not idling, fix any poison-message requeue loop. Protect the broker: a huge backlog forces paging to disk and can hit the memory high watermark → flow control blocks publishers — cap with queue max-length/TTL + DLX to shed/divert rather than OOM. Structural: lazy/quorum queues for big backlogs, faster consumers. RabbitMQ is healthiest with near-empty queues — deep queues are a warning.

Stop blind requeuing. Use retry-with-limit: track delivery/retry count (quorum queues expose x-delivery-count, or keep it in headers) and after N attempts dead-letter it to a DLQ instead of requeuing. Quorum queues support delivery-limit which auto-dead-letters after a set number of redeliveries — the clean built-in fix. Then alert on DLQ depth and inspect/replay. One bad message must never be able to stall the whole pipeline.

Risk is split-brain (both sides diverge). Behavior depends on cluster_partition_handling: pause_minority (the safe default — minority nodes pause so only the majority serves), autoheal, or ignore (dangerous, manual fix). With quorum queues, Raft handles it correctly — majority side keeps accepting writes, minority can't, no divergence (the main reason to use them over deprecated classic mirrors, which could lose messages). Recovery: restore the network, let minority rejoin and resync, verify contents, fix the root network cause. Design: odd node count, pause_minority, quorum queues, AZ spread.

RabbitMQ self-protects via flow control. The memory high watermark (~40% RAM) or disk free-space limit being crossed blocks publishing connections until it recovers (consumers keep draining). Usually a backlog grew (slow/absent consumers) and the broker is defending itself. Fix the real cause: scale consumers / drain the backlog, use lazy or quorum queues to keep memory bounded, cap queues with max-length, and give the node headroom. Don't just raise the watermark blindly — "publishers blocked" means the broker is overwhelmed.

For a message to survive restart you need all of: durable queue + persistent message (delivery mode 2) + durable exchange. Even then there's a small pre-flush window unless you use publisher confirms (broker acks only once safely handled). If any piece is missing (transient queue, non-persistent message, auto-ack consumer losing in-flight work), you lose messages. For real durability under node loss, use quorum queues (replicated). Audit which of these is absent.

Close the loss window at every hop. Publish: durable exchange + queue, persistent messages, publisher confirms (retry on nack/timeout), and mandatory/alternate-exchange so unroutable messages aren't dropped. Storage: quorum queues across 3 nodes/AZs. Consume: manual acks after success, sensible prefetch, idempotent consumers (at-least-once means duplicates on redelivery — dedupe by message id). Failures: DLX + delivery-limit so poison messages park. Monitor confirm/ack rates, queue + DLQ depth, watermarks. RabbitMQ gives at-least-once, not exactly-once — idempotency makes duplicates harmless.

Diagnose slow/few consumers, scale + tune prefetch, fix poison loops; cap with max-length/TTL + DLX or lazy/quorum queues before the memory watermark blocks publishers.

Track delivery count (x-delivery-count / delivery-limit) and dead-letter to a DLQ after N attempts instead of requeuing; alert on DLQ depth.

Risk of split-brain; pause_minority keeps only the majority serving and quorum queues prevent divergence; restore network, let minority resync, verify contents, fix the cause.

Flow control from the memory/disk watermark — usually a backlog from slow/absent consumers; drain it, scale consumers, use lazy/quorum queues, add headroom — don't blindly raise the watermark.

Missing durable queue + persistent message + (ideally) publisher confirms; transient queues, non-persistent messages, or auto-ack lose data — use quorum queues for node-loss durability.

Durable + persistent + publisher confirms + mandatory on publish, quorum queues, manual acks after DB commit, idempotent consumers (dedupe by order id), DLX for failures, monitoring.

Set basic.qos prefetch (e.g. 1–50) so the broker dispatches fairly instead of pushing the whole queue to one fast consumer.

Single active consumer (or one consumer/one queue) with prefetch tuned, and idempotent handling for redeliveries; parallel consumers inherently break strict order.

Deep queues held in RAM (use lazy/quorum queues), too-high prefetch buffering unacked messages, many connections/channels, or unconsumed queues; cap queues + tune prefetch + add memory headroom.

Create new quorum queues, shovel/federate or dual-publish to move traffic, cut consumers over once drained, and retire the mirrored queues — mirrored is deprecated, plan capacity (quorum uses more resources).