Migrating to Quorum Queues with Minimal Code Changes
summary
Quorum queues deliver concrete wins: benchmarks show about 5× throughput and roughly 6× lower publisher latency versus classic mirrored queues, with much more predictable consumer latency; only ~4.4% of queues in the fleet use them. Three migration patterns work with little or no app code change: delete-and-recreate (fast, loses messages), in-place with a shovel (preserves messages), and migrate-by-vhost with federation (zero downtime but can reorder). A broker setting to relax redeclare checks eases transitions.
AI-written summary · about
chapters (10)
- 0:00Quorum Queues migration intro
- 1:01Why migrate to Quorum Queues
- 3:55Classic mirrors still used
- 4:35Preparing migration
- 7:01Demo app overview
- 8:50Method 1: Delete and recreate
- 12:20Method 2: Migrate in place
- 14:53Method 3: Migrate by vhost
- 18:02Migration steps summary
- 19:53Q&A
related talks
46mReal-world Examples of Message Queue Usage: Insights from RabbitMQ
48mA Beginner's Guide to Inter-Service Messaging
23mRethinking Message Queues: PostgreSQL's Role
58mReplacing Legacy Message Queueing Solutions with RabbitMQ
22mLessons Learned from Scaling RabbitMQ in a High-Growth (...)
37mGetting started with ZeroMQ
46mSubatomic, Supersonic, Reactive
42mIt's like 10,000 streams when what you need is a queue