Integration / RabbitMQ Interview Questions
How does RabbitMQ handle high availability?
RabbitMQ offers high availability primarily through queue replication, with two generations of the feature that behave quite differently.
| Classic Mirrored Queues (legacy) | Quorum Queues (recommended) |
| Configured via a mirroring policy; one master, N mirrors. | Configured natively at declare time; replicated via Raft with a leader and followers. |
| Failover could silently lose unsynced messages in some scenarios. | Raft's majority-commit design avoids that class of data loss. |
| Deprecated as of RabbitMQ 3.x moving forward. | The current, actively developed replication mechanism. |
On top of replication, HA also depends on operational choices: distributing nodes across failure domains (racks/AZs), fronting connections with a load balancer or client-side reconnect logic, and picking a sensible cluster_partition_handling strategy for when the network itself is unreliable.
Which replication mechanism is now recommended over classic mirrored queues?
Besides queue replication, what else affects real-world HA?
More Related questions...
