Integration / RabbitMQ Interview Questions
How does RabbitMQ implement the Raft consensus algorithm in quorum queues?
Each quorum queue is backed by its own independent Raft group - a set of replicas spread across cluster nodes that together maintain a single, ordered, replicated log of operations for that queue.
- One replica in the group is elected leader; all client operations (publishes, consumes, acks) for that queue go through the leader.
- The leader appends the operation to its log and replicates it to the follower replicas.
- Once a majority (quorum) of replicas - including the leader - have persisted the entry, it is considered committed and the client is acknowledged.
- If the leader fails, the remaining replicas run a Raft leader election to pick a new leader from among those with the most up-to-date log, and the queue resumes serving without losing committed entries.
Because commitment requires a majority rather than every single replica, the queue tolerates the loss of a minority of its replicas (for a 3-replica group, that means 1 node) without losing data or availability.
In a Raft group, what must happen before a write is considered committed?
In a 3-replica quorum queue, how many replica failures can it tolerate and stay available?
More Related questions...
