Top 25 RabbitMQ Interview Questions and Answers [2026]

TL;DR: RabbitMQ interviews in 2026 test exchange routing, publisher confirms and consumer acks, prefetch, dead-lettering and the choice between classic queues, quorum queues and streams. Candidates should know that RabbitMQ 4.0 removed classic queue mirroring and that 4.3 made Khepri, a Raft-based store, the only metadata store.

RabbitMQ 4.3.0, released on April 23, 2026, removed Mnesia completely, so every cluster now keeps its metadata in Khepri. A cluster now needs a majority of nodes online to stay available, the same rule quorum queues follow.

Anyone still describing mirrored classic queues or pause_minority is describing RabbitMQ 3.

Routing Basics

1. How do exchanges, queues and bindings fit together?

Producers publish to an exchange, never directly to a queue. The exchange copies each message to every queue whose binding matches, and consumers read from queues.

A binding is a rule linking one exchange to one queue, usually with a binding key. This split means producers do not need to know which services consume a message.

A new consumer adds its own queue and binding without any change to the producer.

2. What are the exchange types, and when do you use each?

There are four main types, per the exchanges guide:

• Direct: routes to queues whose binding key equals the routing key. Good for task queues by type, such as resize-image.
• Fanout: copies every message to every bound queue and ignores keys. Good for broadcasting events.
• Topic: matches dotted routing keys against patterns, where * matches one word and # matches zero or more. order.*.created matches order.eu.created.
• Headers: matches on message headers instead of the routing key. Rarely needed.

The default exchange is a direct exchange with no name, to which every queue is bound by its own name. That is why publishing with the queue name as routing key "sends to a queue".

3. What happens to a message that matches no queue?

By default it is dropped silently. Worse, with publisher confirms on, the broker still sends a positive ack, because the exchange handled it correctly.

To find out, publish with the mandatory flag. The confirms guide says the broker then sends a basic.return before the ack.

The other option is an alternate exchange on the exchange, which catches unroutable messages in a queue you can inspect.

4. Queue, exchange and message durability: what does each protect?

A durable queue or exchange survives a broker restart as a definition. A persistent message, published with delivery_mode 2 in AMQP 0-9-1, is written to disk so its content survives too.

You need both for classic queues: a persistent message in a non-durable queue is lost with the queue. Quorum queues are always durable and persist every message, so the flag does not matter there.

None of this helps if the node's disk is lost, which is why replicated queue types exist.

Reliable Delivery

5. How do you make sure a message is never lost?

Cover every hop: confirms on publish, a replicated durable queue, and manual acks on consume. Each covers a different failure, and missing any one leaves a gap.

This gives at-least-once delivery, not exactly-once. A consumer can process a message and crash before its ack reaches the broker, and the message is delivered again.

Consumers must therefore be idempotent, for example by recording processed message IDs.

6. How do publisher confirms work?

After confirm.select, the broker acks each published message once it has taken responsibility for it. For a persistent message in a durable queue, that means after it has been written to disk, or accepted by a majority for a quorum queue.

A basic.nack means the broker could not accept it.

Waiting for each confirm one by one is slow. Most clients publish a batch or stream asynchronously and track outstanding sequence numbers, republishing anything nacked or not confirmed within a timeout.

7. What is prefetch, and how do you choose a value?

Prefetch, set with basic.qos, caps how many unacknowledged messages the broker will push to one consumer. Without it, the broker sends as fast as it can, and one consumer can buffer a huge backlog in memory while others sit idle.

Choose it from processing time and latency. Slow, heavy jobs need a small value, even 1, so work spreads across consumers. Fast consumers need a larger value, or they wait on a network round trip for every message.

The consumer prefetch guide covers the per-consumer setting; global QoS is a deprecated feature in 4.3.

8. What is the difference between ack, nack with requeue and reject?

basic.ack removes the message. basic.nack or basic.reject with requeue=true puts it back for another delivery. With requeue=false the message is dead-lettered if the queue has a dead-letter exchange, or dropped if not.

Requeueing a message that will always fail, such as one with a malformed body, creates a hot loop. Send it to a dead-letter exchange instead. Quorum queues enforce this since 4.0 with a default delivery limit of 20.

9. How do dead-letter exchanges work?

You give a queue a dead-letter exchange by policy or with the x-dead-letter-exchange argument. The queue then republishes messages there when they are rejected without requeue, expire by TTL, or overflow a length limit.

RabbitMQ adds an x-death header with the reason and source queue.

The DLX guide warns that default dead-lettering is at-most-once: a message can be lost if the target queue is unavailable. Quorum queues support at-least-once dead-lettering, which republishes with confirms internally.

10. How do you retry a failed message after a delay?

The classic pattern is a retry queue with a message TTL and a dead-letter exchange pointing back to the work queue. A failed message is sent to the retry queue, waits out the TTL, and is dead-lettered back for another attempt.

Several retry queues with growing TTLs give backoff.

RabbitMQ 4.3 added delayed retry to quorum queues, with a configurable backoff based on delivery count, which removes much of this plumbing. Either way, count attempts and park the message in a final dead-letter queue after a limit.

Queue Types

11. Classic, quorum or stream: how do you choose?

Use a quorum queue for work that must survive a node failure. Use a stream for data that several consumers must read or replay. Keep classic queues for temporary or exclusive queues, where losing messages with a node is acceptable.

The quorum queues guide lists when not to use them: temporary or exclusive queues, high queue churn, and cases that need the lowest possible latency, since Raft consensus adds some.

12. How do quorum queues replicate data?

A quorum queue is a Raft group with a leader and followers on different nodes. A write is confirmed once a majority of members has it, so a three-member queue survives one node failure and a five-member queue survives two.

If the leader's node fails, the remaining majority elects a new leader and the queue keeps working. A minority side of a network partition cannot accept writes, which prevents split-brain.

That is why clusters use an odd number of nodes, usually three or five.

13. How are streams different from queues?

A stream is an append-only log: consuming a message does not remove it. Each consumer picks its start point with the x-stream-offset argument. Options include first, last, next, a numeric offset or a timestamp, per the streams guide.

Messages leave only through retention limits by size or age. That makes streams suit fan-out to many consumers, replay after a bug fix, and large backlogs.

Streams can be used over AMQP, or through the stream protocol plugin for higher throughput.

14. How do you keep message order with several consumers?

A queue delivers in order, but several consumers on one queue process in parallel, so completion order is not guaranteed. Requeued messages also come back out of their original position.

For strict order, use single active consumer, where only one consumer receives messages and another takes over if it fails. To scale, split the work: route by a key, such as customer ID, to several queues, each with one active consumer.

The consistent hash exchange plugin can do that split.

15. How do you stop a queue from growing without limit?

Set a length limit with max-length or max-length-bytes and choose an overflow behaviour. The default, drop-head, discards the oldest messages. reject-publish refuses new ones and nacks them to publishers using confirms.

Per the max length guide, reject-publish-dlx also dead-letters the rejected messages; quorum queues do not support that mode. A length limit handles symptoms.

The real fix is more consumers or less load, and an alert on queue depth tells you when.

Operations

16. What happens when a node runs low on memory or disk?

It raises a resource alarm and blocks every connection that publishes, cluster-wide, until the alarm clears. Consumers keep working, which is how the backlog drains.

The memory threshold defaults to about 60% of available RAM, per the memory guide. In containers the docs recommend an absolute value, because detecting "available" memory there is unreliable.

Clients should watch for connection.blocked so a blocked publisher does not look like a hang.

17. Why does RabbitMQ close a channel with PRECONDITION_FAILED on a slow consumer?

Because of the consumer timeout: if a delivered message stays unacknowledged too long, RabbitMQ closes the channel and requeues its messages. The consumers guide gives a default of 30 minutes.

The timeout limits how long a stuck consumer can hold messages; for quorum queues it also stops unbounded Raft log growth.

Jobs that genuinely take longer should ack early and track progress elsewhere, or have the timeout raised for that queue.

In 4.3 the check moved into the queue types: quorum queues enforce a configurable timeout, while classic queues and streams no longer evaluate one.

18. How many connections and channels should an app open?

Open one long-lived connection per process and use channels for concurrency, typically one channel per thread. Connections are expensive TCP and TLS sessions; channels are light and multiplexed over them.

Two anti-patterns show up in incidents. One is opening a connection per message, which can exhaust the broker's file descriptors. The other is sharing one channel across threads, which client libraries such as the Java client warn against.

Keep publishing and consuming on separate connections so a publisher blocked by an alarm does not stall consumers.

19. Federation or shovel: how do you move messages between clusters?

Both move messages between brokers over AMQP; they differ in setup. Federation links exchanges or queues in different clusters so they behave loosely as one.

A shovel is a simpler consumer-publisher pair that moves messages from one source to one destination.

Use a shovel for migrations and one-way bridges, and federation for sharing an event flow across regions without a single cluster spanning a WAN.

Never stretch one cluster across data centres: Raft-based queues and metadata need low latency between nodes. RabbitMQ 4.2 added local shovels for moving messages within one cluster using internal links.

20. When would you choose Kafka over RabbitMQ?

Choose Kafka when the main need is a long-retention, replayable event log with very high throughput and consumer groups that each read the whole history.

Choose RabbitMQ when you need flexible routing, per-message acks, priorities, delayed retries and work queues.

The gap has narrowed. RabbitMQ streams give a replayable log, and 4.2 added SQL filter expressions for them. A good answer starts from delivery semantics and routing needs, not brand preference.

What Changed Recently

21. What happened to mirrored classic queues?

They are gone. The RabbitMQ 4.0 release notes say classic queue mirroring was removed after three years of deprecation. After an upgrade, mirroring keys in policies have no effect, and classic queues keep working with a single replica.

For replicated data the options are quorum queues and streams. An upgrade plan should find every queue that relied on mirroring and move it to a quorum queue first. A node loss now takes its classic queues' messages with it.

22. What is Khepri, and what changed for clustering?

Khepri is RabbitMQ's Raft-based store for metadata such as users, vhosts, queues, bindings and policies. It was fully supported in 4.0, became the default for new clusters in 4.2.0, and in 4.3.0 replaced Mnesia entirely.

The 4.3 notes spell out the practical effect. A majority of nodes must be online for the cluster to be available.

The cluster_partition_handling settings no longer have any effect, because partition recovery now follows Raft for metadata, quorum queues and streams alike.

23. What did RabbitMQ 4.3 add to quorum queues?

The 4.3.0 release notes list four headline features from a new quorum queue state machine.

They are strict priority queues, delayed retry with increasing backoff, a configurable consumer timeout, and recovery snapshots that shorten restart time.

For interviews, delayed retry matters most. It covers what used to need TTL retry queues and dead-letter loops.

The same release rejects some old settings: declaring a queue with x-queue-mode or x-queue-version set to 1 now fails, and transient non-exclusive queues are refused unless a deprecated feature is enabled.

24. Why does AMQP 1.0 matter in RabbitMQ 4?

Since 4.0, AMQP 1.0 is a core protocol that is always enabled, and the native AMQP 1.0 announcement covers the new implementation. The 4.0 notes say its peak throughput is more than double that of 3.13 on some workloads.

AMQP 1.0 clients can now also declare queues, exchanges and bindings.

AMQP 1.0 is an OASIS and ISO standard, so it opens RabbitMQ to clients written for other brokers. Newer features arrive there first: 4.1 added filter expressions for streams, and 4.2 added SQL filters and Direct Reply-To over AMQP 1.0.

AMQP 0-9-1 remains fully supported.

25. How do SQL filter expressions on streams work?

An AMQP 1.0 consumer attaches to a stream with a SQL-like expression, and the broker only sends matching messages. RabbitMQ 4.2 added them as a stronger version of the property filters in 4.1.

order_type IN ('premium', 'express') AND
(customer_region LIKE 'EU-%' OR customer_region = 'US-CA') AND
NOT cancelled

Filtering on the broker cuts network traffic and client work when each consumer needs a slice of a busy stream.

The expressions read the message's properties and application properties, not its body, so producers must put the fields to filter on in headers. See the stream filtering guide.

Signs of a Strong Answer

• They name all three pieces of reliable delivery (confirms, a replicated queue, manual acks) and admit the result is at-least-once.
• They know an unroutable message is acked unless it is published as mandatory.
• They pick prefetch from job duration, and can explain why a missing prefetch starves other consumers.
• They reach for quorum queues by default in 4.x and know mirroring no longer exists.
• They send poison messages to a dead-letter queue instead of requeueing forever.
• They can explain what a majority requirement means for a three-node cluster during maintenance.

Hiring RabbitMQ Developers

RabbitMQ work usually sits inside a back-end or platform role, so hire for messaging judgment on top of a strong main language.

Second Talent matches companies with pre-vetted back-end engineers experienced with RabbitMQ, quorum queues and event-driven systems, screened with questions like these.

Tell us the stack and we send a shortlist within 24 hours. Start hiring, or see our Kafka and event-driven architecture interview guides.