Keynote: Quorum Queues: A Retrospective
summary
Quorum Queues use Raft to put full queue state into a replicated log (released as a feature in RabbitMQ 3.8, with 3.10 adding message TTL and at‑least‑once dead‑lettering). Classic mirrored queues once lost 35% of confirmed messages in Jepsen tests, so this design trades consensus cost for safety, adds a centralized writer‑head that batches fsyncs, removes in‑memory message copies in 3.10, introduces machine versions for safe upgrades, enforces delivery limits to avoid unbounded log growth, and scales to thousands of queues with single‑queue throughput limits.
AI-written summary · about
chapters (10)
- 0:0006:00 - Quorum Queues timeline
- 6:0113:19 - 2016 | What we needed?
- 13:2016:40 - Consesus is Costly
- 16:4118:52 - Availability
- 18:5221:18 - Throughput
- 21:1924:11 - Throughput vs Many Queues
- 24:1225:42 - Throughput | Resource use: Local Delivery
- 25:4329:40 - Maintainable
- 29:4140:28 - Features
- 40:2951:14 - QnA
related talks
55mImplementing Raft in RabbitMQ
37mImplementing Raft in RabbitMQ
43mRa: a Raft implementation
26mBreaking Magical Barriers
29mKeynote: The Power of Queues
50mPanel discussion: The new RabbitMQ Streams
16mTo queue or not to queue, that is the question.
47mDistributed Systems: When Democracy and Computer Science Come Together
