Quorum Queues: Migrating Small Applications from Classic Mirrored Queues in RabbitMQ 3.9 Without Downtime

Question

GoalAchieve a zero‑downtime migration of a small application that currently uses Classic mirrored queues to Quorum Queues in a RabbitMQ 3.9+ cluster.Constraints and UncertaintyThe migration requires a dual‑publish bridge where producers write to both queue types during cutover, introducing possible message duplication and increased latency. The performance trade‑off between Quorum Queue’s strong consistency and Classic queue’s lower latency remains an unresolved behavior for many users, affecting the decision on how long to run the bridge and when to switch traffic.What is the optimal duration for the dual‑publish phase that limits duplication risk while keeping latency acceptable?How should the application detect and deduplicate messages that may appear in both queues during the cutover to preserve exactly‑once processing?When should traffic be switched entirely to the Quorum Queue to guarantee consistency without causing a noticeable pause?

Tasadduq Burney · Answer

Migration objective
Move a small application from classic mirrored queues to quorum queues in RabbitMQ 3.9+ with zero downtime.
Dual‑publish bridge duration
The research brief recommends a dual‑publish phase of 1 to 2 times the time needed for the classic queue to drain. For small workloads this often translates to roughly 30 to 120 minutes, but the exact window depends on your consumer drain rate and current backlog. Measure the drain rate before fixing a duration.
Message deduplication
Producers writing to both queue types during cutover may cause duplicate deliveries. Consumers can deduplicate by processing messages that carry a unique message-id or correlation-id, storing processed IDs in a persistent store, and performing idempotent operations (for example, database upserts keyed by ID). Without idempotent handling, duplicates may trigger repeated side-effects.
Traffic cutover timing
Switch traffic entirely to the quorum queue only after the classic queue shows consumer lag = 0 and a grace period of at least one message TTL has elapsed. This ensures no in‑flight messages remain on the classic queue. Verify with rabbitmqctl list_queues name state and confirm the classic queue is paused or deleted after migration.
What is needed to finalize the recommendation
To refine the exact dual‑publish duration and cutover point, the current consumer lag on the classic queue and the configured message TTL should be provided. These two values will allow the migration plan to move from an approximate range to a precise, actionable window.

Quorum Queues: Migrating Small Applications from Classic Mirrored Queues in RabbitMQ 3.9 Without Downtime

Goal

Constraints and Uncertainty

1 answer

Migration objective

Dual‑publish bridge duration

Message deduplication

Traffic cutover timing

What is needed to finalize the recommendation

Your perspective belongs here.

0 question comments