RabbitMQ Interview Questions

A set of practical RabbitMQ interview questions — the kind that check whether you've actually configured routing and reliability, not just read the word "AMQP" once.

Q: What are the main exchange types, and when would you pick each one? Direct exchanges route by exact routing-key match — a fixed, small set of distinct message types, each going to exactly one queue. Fanout exchanges ignore the routing key and broadcast to every bound queue — the right fit for an event that several unrelated consumers each independently care about. Topic exchanges route via wildcard pattern matching (* for one word, # for zero or more) — used when different consumers need different slices of the same stream, sliced along more than one dimension at once (e.g., by region and by event type). A headers exchange also exists, routing on message header values instead of the routing key, but it's rarely used compared to the other three.

Q: What's the difference between ack and nack, and what does the requeue flag actually control? ack tells the broker processing succeeded and the message can be permanently removed. nack tells it processing failed, and the requeue flag decides what happens next: true puts the message straight back on the queue for immediate redelivery, false either drops it or — if a dead-letter exchange is configured on the queue — routes it there instead of destroying it.

Q: What is a dead-letter exchange, and what actually triggers a message being sent to one? A DLX is just a regular exchange configured on a queue as the destination for messages that can't be delivered normally. Three things trigger it: a consumer rejecting a message with requeue: false, a message sitting past its configured TTL, or a queue hitting a configured maximum length. Without one configured, all three of those outcomes either silently drop the message or, in the reject-and-requeue case, loop it forever.

Q: What has to be true for a message to survive a RabbitMQ broker restart? Both the queue and the message need to be configured for it independently: the queue must be declared durable: true (so its definition survives a restart), and the message must be published with persistent: true / delivery mode 2 (so its content is written to disk, not just held in memory). Either one alone isn't enough — a durable queue with non-persistent messages loses everything still queued when the broker restarts.

Q: What problem do publisher confirms solve that consumer acknowledgments don't? Consumer acks cover the broker-to-consumer leg of a message's journey — did the consumer actually finish processing it. Publisher confirms cover the opposite leg — did the broker actually receive and durably store the message in the first place, since a plain channel.publish() call returning success only means the bytes left your process, not that RabbitMQ has them. A pipeline that only acks on the consumer side has no way to detect a message that was silently lost between the producer and the broker.

Q: Why does prefetch (QoS) matter once you have more than one consumer on a queue? Without a prefetch limit, RabbitMQ will keep pushing messages to whichever consumer is fastest to acknowledge, with no cap on how many unacknowledged messages that consumer can be holding — so one fast or greedy consumer can end up processing nearly everything while its siblings sit idle. Setting channel.prefetch(n) caps in-flight unacked messages per consumer, which is what makes messages actually distribute across multiple consumers instead of piling up on one.

Q: Does clustering RabbitMQ nodes automatically make a queue's messages highly available? No — clustering nodes together only replicates metadata (which exchanges, queues, and bindings exist) across the cluster by default. A queue's actual messages still live on whichever single node hosts it unless that queue is explicitly declared as a mirrored (legacy) or quorum (recommended) queue, which is what actually replicates message content across nodes.

Q: Why are quorum queues recommended over classic mirrored queues for new deployments? Quorum queues use the Raft consensus algorithm, which only considers a write successful once a majority of replicas have durably persisted it — so a failover can never silently lose a message that was already acknowledged. Classic mirrored queues use an older replication protocol that doesn't guarantee every mirror is fully caught up before a promotion, which under certain failure and network-partition scenarios can lose messages the master had already acknowledged; RabbitMQ has deprecated mirrored queues in favor of quorum queues for exactly this reason.

Q: What's the standard fix for messages that are too large to publish directly to RabbitMQ? The claim-check pattern: store the large payload in something built for large objects (S3, a blob store) and publish only a small reference — an ID or object key — to RabbitMQ instead. Keeping messages small (roughly under 100–128KB as a rule of thumb) avoids bloating memory usage and slowing down replication across a mirrored or quorum queue, both of which have to move the full message content, not just a reference to it.

Q: Why should an application reuse one AMQP connection instead of opening a new one per message? Opening a connection requires a full TCP handshake plus AMQP protocol negotiation, which is comparatively expensive — doing that on every single publish makes connection overhead the dominant cost of the whole pipeline long before the broker itself becomes the bottleneck. The standard pattern is one long-lived connection per process, reused for its lifetime, with one or a small pool of channels (which are much cheaper to open) reused across many publish/consume calls.

Q: If a RabbitMQ queue's depth looks fine in a single snapshot, what other metric do you need to know it's actually healthy? Consumer utilization. A queue depth of several thousand messages could mean consumers are overwhelmed and falling behind, or it could just mean a burst arrived a moment ago and is already draining quickly — those look identical in one snapshot. Consumer utilization near 100% alongside a queue depth that keeps climbing over time is what actually distinguishes "genuinely backed up" from "handling a normal burst."