🗳️ Quorum Queues vs Classic Mirrored Queues With AI

I held onto classic mirrored queues a year longer than I should have. They worked, the cluster was stable, and “if it isn’t broken” is a powerful sedative. Then a network partition split my three-node cluster, the mirrored queue’s master and a mirror disagreed about which messages existed, and the automatic-heal policy I’d set silently discarded one side. I lost messages I’d promised were durable. That’s the failure mode classic mirroring was always capable of, and it’s precisely the one quorum queues are built to eliminate.

Deciding between quorum queues and classic mirrored queues — and planning the migration — is a reasoning-heavy task with real trade-offs, which makes it good AI territory. The model knows the consistency models cold, it’s good at laying out the migration steps, and it’ll flag the gotchas (no lazy mode, different memory profile) that you’d otherwise hit in production. What it can’t do is run the migration on your staging cluster and watch what actually happens to throughput, so that part stays yours.

Make the AI argue both sides

The worst way to use AI here is to ask “should I use quorum queues?” and get a one-word answer. Ask it to argue the trade-off with your constraints, because the right call genuinely depends on your workload.

I run a 3-node RabbitMQ cluster currently using classic mirrored queues with ha-mode: all. My workload is mostly durable work queues, moderate throughput, occasional very large backlogs (millions of messages) during batch jobs. Compare quorum queues against classic mirrored queues for my case. Cover: consistency under network partition, memory behavior during large backlogs, the lack of lazy mode in quorum queues, throughput differences, and what features I’d lose. Then give me a recommendation and the migration plan.

A good answer is direct: quorum queues use a Raft consensus model that won’t silently discard messages on partition the way mirrored queues can, mirrored queues are deprecated, so quorum is the strategic choice. But it should also warn you that quorum queues hold more in memory per message and don’t support the old lazy-queue mode, so your million-message batch backlogs need a x-max-in-memory-length cap or they’ll pressure the node differently than lazy mirrored queues did.

The consistency difference that actually matters

The reason this migration is worth the pain comes down to one behavior. Ask the AI to explain it plainly:

Classic mirrored queues use a master-mirror model where, on a network partition, the two sides can diverge, and depending on your partition-handling policy, the broker may discard messages from one side when healing. Quorum queues use Raft: a write is only confirmed once a majority of nodes have it, so a minority partition simply can’t confirm new writes and no committed message is lost when the partition heals. You trade a bit of latency and memory for the guarantee that confirmed messages survive.

That’s the whole argument. If you’ve ever lost a “durable” message to an auto-heal, you already know why it’s worth it.

Declare and inspect on staging first

You don’t migrate by flipping a policy — quorum is a queue type set at declaration, so existing mirrored queues have to be drained and recreated. Stand the new ones up on a staging cluster and check the cluster’s view of them.

# Declare a quorum queue (type is fixed at creation)
rabbitmqadmin declare queue name=payments durable=true \
  arguments='{"x-queue-type":"quorum"}'

# Confirm type and which nodes hold members
rabbitmqctl list_queues name type members leader

# Quorum-specific health: check the leader and follower state
rabbitmqctl quorum_status payments

quorum_status is the command with no mirrored-queue equivalent — it shows the Raft leader and whether followers are caught up. Watch it during a simulated node failure on staging to confirm a follower gets promoted cleanly and no messages vanish.

Cap memory, because there’s no lazy mode

This is the gotcha that gets people. Classic queues had a lazy mode that paged messages to disk aggressively, keeping memory flat under huge backlogs. Quorum queues don’t have lazy mode. For your batch-job backlogs, set a cap so the queue doesn’t hold the whole backlog in memory.

# Limit how many messages quorum queues keep in memory
rabbitmqctl set_policy quorum-mem "^payments$" \
  '{"x-max-in-memory-length":50000}' --apply-to queues

If the AI doesn’t mention this when you describe large backlogs, prompt it: “I have million-message backlogs and quorum queues have no lazy mode — how do I keep memory bounded?” The x-max-in-memory-length policy is the answer.

Where AI gets it wrong

The model occasionally suggests you can convert a mirrored queue to quorum in place by changing a policy. You can’t — the queue type is immutable after declaration, so migration means draining consumers, recreating the queue as quorum, and repointing publishers. Always verify any “just change the policy” claim against the fact that x-queue-type is set at creation only.

It can also undersell the memory difference. Quorum queues keep an in-memory index, so a node sized comfortably for lazy mirrored queues may need more headroom. Ask it to be explicit about per-message memory, and validate the real footprint on staging under your peak backlog before you trust the sizing.

My migration loop

Have the AI argue both sides against my actual workload, produce a migration plan, and surface the lazy-mode and memory gotchas. Then I stand up quorum queues on a staging cluster, run quorum_status through a simulated node failure to confirm clean leader election and zero message loss, and load up a peak-sized backlog with the memory cap in place to confirm the node holds. The AI compresses the research and remembers the gotchas; the staging cluster proves the consistency and memory behavior before I touch production.

These comparison and migration prompts sit with the rest of my prompts, and the RabbitMQ category covers the publisher-confirm patterns that pair with quorum queues for genuine zero-loss delivery.