RabbitMQ clustering, quorum queues, federation and shovels: when to use each
Updated July 21, 2026
Use RabbitMQ clustering to make several nearby nodes operate as one logical broker. Use quorum queues inside that cluster when important queue contents must be replicated. Use federation to connect independent brokers or clusters asynchronously across unreliable or wide-area networks. Use a Shovel when you need an explicit message pump from a source queue to a specific destination.
These mechanisms solve different problems and can be combined. A common design is a three-node cluster in each region, quorum queues for critical local workloads, and Federation or Shovel links between the regional clusters.
RabbitMQ clustering vs quorum queues vs federation vs Shovels
| Mechanism | Boundary | What it does | Best fit |
|---|---|---|---|
| Clustering | Nodes on a reliable, low-latency network | Creates one logical broker and replicates broker definitions | Local availability, connection capacity, and one shared namespace |
| Quorum queue | Several nodes in one cluster | Replicates one queue's messages with a Raft majority | Long-lived, durable queues where data safety matters |
| Federation | Independent brokers or clusters | Asynchronously links selected exchanges or queues over AMQP | Cross-region event flow, distributed work, and loose coupling |
| Shovel | Independent endpoints, clusters, or virtual hosts | Consumes from a source and republishes to a chosen destination | Controlled transfers, migrations, drains, and protocol bridging |
None of the four choices eliminates the need for publisher confirms, consumer acknowledgements, idempotent processing, backups, monitoring, or tested failure recovery.
When to use RabbitMQ clustering
A RabbitMQ cluster makes multiple nodes behave as one logical broker. Virtual hosts, exchanges, bindings, users, permissions, policies, and other definitions are available throughout the cluster. A client connected to one node can use non-exclusive queues whose leaders are hosted by another node.
Clustering is designed for nodes with reliable connectivity and LAN-like latency. Cluster nodes form a tightly coupled system, must run compatible RabbitMQ and Erlang versions, and communicate continuously. Do not stretch a RabbitMQ cluster across regions or an unreliable WAN; operate an independent cluster in each location and connect them with Federation or Shovels.
What clustering does not do automatically
- It does not replicate every queue's messages. A classic queue has one replica. If its node is unavailable, that queue is unavailable even though the rest of the cluster can be running.
- It does not balance clients by itself. Applications need multiple endpoints, connection recovery, DNS, or a suitable load balancer so they can reconnect to another healthy node.
- It does not guarantee balanced leaders. Monitor queue and stream leader placement and rebalance when one node carries a disproportionate workload.
- It is not a remote disaster-recovery copy. Nodes share one logical broker and one administrative failure domain. Independent clusters provide a cleaner regional or operational boundary.
RabbitMQ strongly discourages two-node clusters because losing either node removes the majority required by consensus-based components. Three nodes are the usual starting point. Place them in separate failure domains on the same low-latency network and test node loss, restart, and client reconnection.
See the current RabbitMQ clustering guide for cluster formation, peer discovery, networking, node maintenance, and version compatibility.
When to use RabbitMQ quorum queues
A quorum queue is a durable, replicated queue type inside a RabbitMQ cluster. Each quorum queue has a leader and followers on different nodes. Operations are replicated through the Raft consensus algorithm, and a majority of the queue's members must remain available for the queue to operate.
The default group size is three members. A three-member quorum queue can tolerate one unavailable member; a five-member queue can tolerate two. Odd member counts are preferred because adding a fourth member increases replication work without allowing a second failure. Larger groups also add disk and network cost, so three is the practical default for most workloads.
Good quorum queue workloads
- orders, payments, commands, and other business-critical work;
- durable queues expected to exist for a long time;
- workloads that use publisher confirms and manual consumer acknowledgements; and
- systems that prefer consistency and data safety over accepting operations without a majority.
When a quorum queue is a poor fit
- temporary, exclusive, or connection-scoped queues;
- workloads where the lowest possible latency matters more than replication;
- very large numbers of short-lived queues; or
- repeatable reads, long retained histories, and large fan-outs, where a RabbitMQ stream may fit better.
Quorum queues always persist their data and replicate every operation, so fast disks and realistic load testing matter. A successful publisher confirm is also essential: replication cannot protect a message the publisher never confirmed as accepted.
Queue type is selected at declaration and cannot be changed in place. Create a new quorum queue and perform a controlled migration when replacing a classic queue. Classic mirrored queues are no longer an option: their mirroring feature was removed in RabbitMQ 4.0. Read the official quorum queue guide before migrating queue types or changing membership.
Adding a cluster node is not enough
Existing quorum queues do not necessarily gain a replica on a newly added node. Review member placement and use RabbitMQ's membership-management or continuous-reconciliation facilities where appropriate. Before removing a node, verify that doing so will not take any quorum queue or stream below a majority.
Where RabbitMQ streams fit
Streams are another replicated data type, but they provide an immutable, append-only log rather than destructive queue consumption. Multiple consumers can reread retained entries independently. Choose a stream for retained history, large backlogs, replay, or high-throughput fan-out; choose a quorum queue for acknowledged work that should leave the queue after successful processing.
QueueExplorer can browse streams page by page, jump to their beginning, end, or a specific offset, and append new messages. Existing stream entries cannot be edited, moved, or deleted individually. See the RabbitMQ stream browsing guide.
When to use RabbitMQ Federation
The Federation plugin links selected exchanges or queues on independent RabbitMQ brokers or clusters. Links use AMQP client connections, operate asynchronously, reconnect after failures, and tolerate intermittent WAN connectivity. The connected clusters keep separate users, virtual hosts, policies, versions, capacity, and availability.
Federation is configured on the downstream side with upstream connection definitions and policies that select which exchanges or queues participate. It does not automatically copy the rest of the broker schema. Recreate or synchronize the required exchanges, queues, bindings, policies, and permissions separately.
Federated exchanges and federated queues are different
| Federation type | Behavior | Typical use |
|---|---|---|
| Exchange federation | Republishes relevant upstream message flow to a downstream exchange | Regional event distribution, pub/sub, or selected cross-cluster routing |
| Queue federation | Moves messages toward remote consumers when local consumers are unavailable | A logical work queue distributed across sites with consumer locality |
Use exchange federation when remote sites should receive matching events. Use queue federation when workers in several locations should share work rather than receive independent copies. Queue federation favors consumers local to the message and is not a broadcast mechanism.
Federation is asynchronous, so it is not an exact synchronous mirror or a zero-data-loss substitute for local quorum replication. Plan for link lag, duplicates during failure recovery, routing differences, and a controlled cutover if using it for migration or warm standby. Monitor link status and secure remote connections with TLS and dedicated least-privilege credentials.
See RabbitMQ's guides to the Federation plugin, federated exchanges, and federated queues.
When to use a RabbitMQ Shovel
A Shovel is an explicit message-transfer worker. It consumes from a source, republishes to a destination, and can use acknowledgements and publisher confirms to handle failures. Source and destination can be different clusters, virtual hosts, or supported AMQP protocols. A Shovel can also run on a cluster that is separate from both endpoints.
Use a Shovel when the transfer should happen unconditionally and you want direct control over its source, destination, reconnect behavior, acknowledgement mode, and message properties. Typical cases include:
- draining a queue during a blue-green RabbitMQ migration;
- moving a backlog from one virtual host or cluster to another;
- bridging an AMQP 0.9.1 endpoint with an AMQP 1.0 endpoint;
- feeding a dedicated processing or archive destination; and
- running a temporary or permanent point-to-point transfer without application code.
Dynamic Shovels are the modern default
Dynamic Shovels are stored as runtime parameters and can be created, changed, restarted, or removed without a broker restart. Static Shovels live in node configuration and are harder to change operationally. RabbitMQ recommends dynamic Shovels unless a specific deployment requirement calls for static configuration.
A Shovel is not an atomic cross-broker transaction. With the safer confirmation-based acknowledgement mode, a failure at an uncertain point can still result in redelivery and a duplicate at the destination. Preserve stable message IDs and make consumers idempotent. Also decide whether the destination topology should be predeclared or created by the Shovel.
See the current Shovel guide and dynamic Shovel configuration.
Federation or Shovel?
| Question | Choose Federation | Choose Shovel |
|---|---|---|
| What drives transfer? | Federated topology and remote routing or consumer demand | An explicit source-to-destination pipeline |
| Should messages always move? | Not necessarily; exchange bindings or queue demand influence transfer | Yes, while the Shovel is running |
| Primary use | Ongoing distributed messaging between sites | Controlled movement, migration, or protocol bridging |
| Topology model | Policies apply to exchanges or queues | Each worker has an explicit source and destination |
Common RabbitMQ architecture examples
High availability in one region
Run a three-node cluster across separate local failure domains. Let clients connect through multiple endpoints or a health-aware load balancer. Use quorum queues for critical durable work, and keep temporary reply or disposable queues classic when replication would add cost without useful safety.
Active applications in several regions
Run an independent cluster in each region. Use federated exchanges when each region needs selected events from another region. Use federated queues only when consumers should share work across locations and the locality rules match the application.
Blue-green migration to a new RabbitMQ cluster
Export and import the RabbitMQ schema, test the target, then use Federation or a Shovel to transfer the required message flow while applications are cut over. Stop or redirect publishers, drain the remaining source backlog, verify destination counts and consumers, and keep the source available until rollback is no longer required.
A one-time transfer of selected messages
A permanent Shovel can be excessive for a small manual correction. QueueExplorer can copy or move selected messages between queues after you filter and review them. Use a Shovel for an automated stream of deliveries, not for an arbitrary visual selection.
Free trial for Windows, macOS, and Linux
Design and operations checklist
- Use an odd number of cluster nodes and quorum members; start with three unless testing proves another size is needed.
- Keep cluster nodes on a reliable, low-latency network instead of stretching one cluster across regions.
- Place replicas in distinct failure domains and verify queue leader and member distribution.
- Give clients multiple endpoints and test automatic recovery after a node or load balancer target fails.
- Use publisher confirms, manual consumer acknowledgements, stable message IDs, and idempotent consumers.
- Export and protect RabbitMQ definitions, but remember that definition exports do not contain queued messages.
- Secure Federation and Shovel links with TLS and dedicated least-privilege credentials.
- Monitor cluster health, quorum availability, link status, backlog, redeliveries, dead letters, and disk alarms.
- Test network partitions, node replacement, failed transfers, duplicate delivery, and regional cutover before production.
Common mistakes
- Assuming a cluster replicates all messages. Only replicated data types such as quorum queues and streams place message replicas on several nodes.
- Replacing mirrored classic queues with ordinary classic queues. RabbitMQ 4.x removed classic queue mirroring; critical mirrored queues need an intentional quorum-queue or stream migration.
- Using Federation as an exact database replica. It transfers selected message flow asynchronously and requires separate schema and cutover planning.
- Using a stretched cluster for regional disaster recovery. WAN latency and partitions conflict with clustering's tight coupling and quorum requirements.
- Ignoring duplicates. Cross-cluster transfers must recover from uncertain failures, so consumers should tolerate redelivery.
Frequently asked questions
Do I need quorum queues if I already have a RabbitMQ cluster?
Use quorum queues for messages that must remain available after a queue leader's node fails. A cluster makes the queue visible from every node, but an ordinary classic queue still has only one replica.
Can a RabbitMQ cluster span two data centers?
RabbitMQ does not recommend clustering over a WAN. Use an independent cluster in each data center and connect them with Federation or Shovels according to the required message flow.
Is Federation a replacement for quorum queues?
No. Quorum queues synchronously replicate a queue within one cluster using a majority. Federation asynchronously transfers selected message flow between independent brokers or clusters.
Should I use a three-node or five-node quorum queue?
Three members tolerate one unavailable member and are the normal starting point. Five tolerate two but require more replication work. Choose five only when the additional failure tolerance justifies the capacity and latency cost.
Can I convert a classic queue into a quorum queue?
Queue type cannot be changed in place. Declare a new quorum queue, reproduce its bindings and policies, move or drain messages, switch applications, and remove the old queue only after validation.
Can Federation and Shovels be used together?
Yes. For example, Federation can provide an ongoing regional event flow while a temporary Shovel drains one specific backlog during a migration. Monitor them independently and make sure their routes cannot create duplicates or loops unintentionally.
For the official high-level comparison, see RabbitMQ's distributed messaging guide. For visual inspection and troubleshooting, see the RabbitMQ GUI guide.
QueueExplorer: a better way to inspect and manage RabbitMQ
See what is happening in RabbitMQ and resolve message problems without writing one-off tools. Browse queues and streams, inspect message contents, and manage your RabbitMQ environment from one desktop application. Try it free on Windows, macOS, or Linux.