Quorum queues in RabbitMQ 3.10 provide a safer form of dead lettering that uses at-least-once guarantees for the message transfer between queues. This blog post explains everything you need to know to start using at-least-once dead lettering.
This post also introduces two other RabbitMQ 3.10 features: message Time-To-Live (TTL) for quorum queues and Prometheus metrics for dead lettered messages.
| Be aware this post has out of date information |
|---|
| RabbitMQ now has Disaster Recovery capabilities in the commercial editions via the Warm Standby Replication feature |
In this post I am going to cover perhaps the most commonly asked question I have received regarding RabbitMQ in the enterprise.
How can I make RabbitMQ highly available and what architectures/practices are recommended for disaster recovery?
RabbitMQ offers features to support high availability and disaster recovery but before we dive straight in I’d like to prepare the ground a little. First I want to go over Business Continuity Planning and frame our requirements in those terms. From there we need to set some expectations about what is possible. There are fundamental laws such as the speed of light and the CAP theorem which both have serious impacts on what kind of DR/HA solution we decide to go with.
Finally we’ll look at the RabbitMQ features available to us and their pros/cons.