Quorum Queues
IntermediateQuorum queues use the Raft consensus algorithm for data safety with leader election; they offer stronger durability guarantees than classic mirrored queues in clustered setups.
Overview
Quorum queues are the modern, recommended queue type for durable message storage in RabbitMQ clusters (introduced in RabbitMQ 3.8, now the default recommendation over classic mirrored queues). They use the Raft distributed consensus algorithm to replicate messages to a quorum (majority) of cluster nodes. A write is acknowledged only when a majority of nodes have persisted it — providing strong durability guarantees even in the face of node failures. Unlike classic mirrored queues (which can lose messages on network partition), quorum queues guarantee no data loss as long as a majority of nodes are healthy. The trade-off is higher latency (quorum write round-trip) and higher memory usage than a non-replicated classic queue.
Declaring a Quorum Queue
Quorum queues are always durable (durability is required by design). Declare them with the x-queue-type=quorum argument. The initial-quorum-queue-size argument controls how many nodes hold a copy (default: 3, or all nodes if fewer than 3 exist).
// Low-level AMQP client
Channel channel = connection.createChannel();
Map<String, Object> args = new HashMap<>();
args.put("x-queue-type", "quorum");
args.put("x-quorum-initial-group-size", 3); // default: use 3 nodes
// Quorum queues are always durable=true — non-durable is not supported
channel.queueDeclare("orders-quorum", true, false, false, args);
// Spring AMQP
@Bean
public Queue ordersQuorumQueue() {
return QueueBuilder.durable("orders-quorum")
.quorum() // sets x-queue-type=quorum
.quorumInitialGroupSize(3)
.build();
}
# OR via rabbitmq.conf — make quorum the default policy
# Match all queues with a policy:
rabbitmqctl set_policy quorum-queues ".*" \
'{"queue-mode":"default","x-queue-type":"quorum"}' \
--apply-to queuesQuorum vs Classic Mirrored Queues
Classic mirrored queues (ha-mode=all policy) were the old HA solution. They had significant problems: on network partition, all mirrors could independently become masters (split-brain), causing message duplication and loss. RabbitMQ 3.x deprecated classic mirrored queues. Quorum queues fix this with Raft consensus:
- Only the current leader accepts writes; followers replicate. - A write completes only when majority (quorum) of nodes persist it. - On leader failure, Raft elects a new leader from nodes with the most up-to-date replica — no split-brain. - Durability guarantee: messages survive as long as a majority of quorum members are healthy.
# Old approach (deprecated) — classic mirrored queue via policy
rabbitmqctl set_policy ha-all ".*" \
'{"ha-mode":"all","ha-sync-mode":"automatic"}' \
--apply-to queues
# Problems: split-brain on partition, inconsistent sync, message loss
# New approach — quorum queue (Raft-based, no split-brain)
rabbitmqctl set_policy quorum-policy "^critical." \
'{"x-queue-type":"quorum"}' \
--apply-to queues
# Applies quorum type to all queues whose name starts with "critical."
# Key differences:
# Feature | Classic Mirrored | Quorum Queue
# ---------------------|-------------------|--------------
# Algorithm | simple mirroring | Raft consensus
# Split-brain risk | YES | No (Raft prevents it)
# Message loss on fail | Possible | No (quorum write)
# Memory usage | Lower | Higher (Raft log)
# Throughput | Higher | Lower (quorum round-trip)
# Max priority | 255 | None (not supported)Poison Message Handling — delivery-limit
Quorum queues have built-in poison message protection via the x-delivery-limit argument. If a message is nacked and requeued more than delivery-limit times, it is automatically dead-lettered (routed to the DLX if configured) or discarded. This prevents a broken message from cycling forever without a DLX or retry counter in application code.
// Quorum queue with delivery limit — automatic poison message protection
@Bean
public Queue criticalOrderQueue() {
return QueueBuilder.durable("critical-orders")
.quorum()
.withArgument("x-delivery-limit", 5) // dead-letter after 5 requeue attempts
.withArgument("x-dead-letter-exchange", "orders.dlx")
.build();
}
// With this config, application code is simpler:
@RabbitListener(queues = "critical-orders")
public void onOrder(Order order, Channel channel,
@Header(AmqpHeaders.DELIVERY_TAG) long tag) throws IOException {
try {
orderService.process(order);
channel.basicAck(tag, false);
} catch (TransientException e) {
channel.basicNack(tag, false, true); // requeue — quorum tracks delivery count
// After 5 requeues, quorum automatically dead-letters — no manual counter needed
}
}Key Points to Remember
- 1Quorum queues use Raft consensus — a write is acknowledged only when a majority of nodes persist it, preventing data loss.
- 2Quorum queues replace deprecated classic mirrored queues; they eliminate split-brain scenarios on network partitions.
- 3Always durable by design — non-durable quorum queues are not supported.
- 4x-delivery-limit on a quorum queue automatically dead-letters messages that are nacked and requeued too many times — built-in poison message protection.
- 5Trade-off: quorum queues have higher write latency (Raft round-trip) and more memory usage than non-replicated classic queues.
- 6For production clusters, default to quorum queues for any queue that holds data you cannot afford to lose.
Interview Questions
Sign in to ask AriaWhat is a quorum queue and how does it differ from a classic mirrored queue?
How does the Raft algorithm ensure message durability in a quorum queue?
What is x-delivery-limit on a quorum queue and what problem does it solve?
Why were classic mirrored queues deprecated in favour of quorum queues?
How many nodes can fail in a 5-node cluster with quorum queues before messages are lost?
Ask Aria about Quorum Queues
Your personal AI tutor — ask anything about this concept
Revision Status
Personal Notes
Sign in to save personal notes for this topic.
Discussion
Sign in to join the discussion.