A quorum-based system doesn’t actually need a majority of nodes to be up and running for you to make progress; it just needs a majority of nodes to agree on what progress to make.
Imagine a distributed database where multiple copies of the data exist across different servers. If you want to update a record, you can’t just pick one server and tell it to change. What if that server crashes immediately after? You’d have an inconsistent state.
Quorum systems solve this by requiring operations to be acknowledged by a certain number of nodes, not necessarily a majority of available nodes, but a majority of the total configured nodes. Let’s say you have 5 nodes in your cluster and your quorum is set to 3.
Here’s how a read operation might work with a quorum of 3:
- A client requests data from a node.
- That node contacts other nodes to gather the latest version of the data.
- To confirm the read, it needs acknowledgments from at least 3 nodes (the quorum).
- Once 3 nodes confirm they have the data, the client receives it.
And for a write operation:
- A client sends a write request to a node.
- That node broadcasts the write to other nodes.
- It waits for acknowledgments from at least 3 nodes.
- Only after receiving 3 acknowledgments does it consider the write successful and inform the client.
This mechanism ensures that any successful write is guaranteed to be seen by at least quorum nodes. Since quorum is typically greater than N/2 (where N is the total number of nodes), any two quorums must overlap on at least one node. This overlap is the key to consistency. If W is the number of nodes that must acknowledge a write and R is the number of nodes that must respond to a read, and W + R > N, then any read is guaranteed to see the latest write. In many systems, W = R = quorum.
Consider a system with 5 nodes and a quorum of 3.
- Scenario 1: All nodes are up.
- Read: Client asks for data. Node A gets data from B, C, and D (3 nodes). Client gets data.
- Write: Client writes data. Node A writes to B, C, and D (3 nodes). Client gets confirmation.
- Scenario 2: One node is down (Node E).
- Read: Client asks for data. Node A gets data from B, C, and D (3 nodes). Client gets data. Still works.
- Write: Client writes data. Node A writes to B, C, and D (3 nodes). Client gets confirmation. Still works.
- Scenario 3: Two nodes are down (Node D and E).
- Read: Client asks for data. Node A tries to get data. It contacts B and C. It needs one more. It can’t get it from D or E. It cannot satisfy the quorum. The read fails.
- Write: Client writes data. Node A tries to write to B and C. It needs one more. It can’t get it from D or E. It cannot satisfy the quorum. The write fails.
This is the core idea: if you can’t get quorum nodes to agree, you can’t make progress. This prevents a partition (where the network breaks into disconnected groups) from allowing two different groups to independently make conflicting updates.
Let’s look at a real-world example: Apache ZooKeeper. ZooKeeper uses a consensus protocol called ZAB (ZooKeeper Atomic Broadcast). While not strictly a quorum system in the W+R>N sense for all operations, its leader election and state synchronization rely on a majority vote. If fewer than a majority of ZooKeeper servers are available, the ensemble cannot elect a leader or process client requests that modify the state.
Here’s a snippet of ZooKeeper configuration:
tickTime=2000
dataDir=/var/lib/zookeeper
clientPort=2181
initLimit=10
syncLimit=5
server.1=zk1.example.com:2888:3888
server.2=zk2.example.com:2888:3888
server.3=zk3.example.com:2888:3888
server.4=zk4.example.com:2888:3888
server.5=zk5.example.com:2888:3888
In this 5-node ZooKeeper ensemble, a majority is 3 nodes. If any 3 nodes agree on a new leader or a state change, that change is considered committed. If only 2 nodes are available, they cannot form a majority and the system becomes read-only or unavailable for writes.
The magic of quorum systems is how they balance availability and consistency. By setting the quorum size appropriately, you can tune how many nodes must be available for operations to succeed. A higher quorum (e.g., 4 out of 5) means stronger consistency but lower availability if nodes fail. A lower quorum (e.g., 3 out of 5) means higher availability but potentially weaker consistency guarantees if not carefully managed with W and R values.
Most people think of quorum as simply "more than half the nodes must be up." The subtle but crucial point is that the quorum is often a majority of the total configured nodes, not a majority of the currently reachable nodes. This prevents a network partition from creating two independent, functional clusters that would diverge. If a node is truly lost (not just temporarily unreachable), it needs to be removed from the configuration and a new node added to maintain the quorum’s ability to reach the desired number of nodes.
The next thing you’ll grapple with is how different quorum implementations (like Raft vs. Paxos vs. ZAB) handle network partitions and node failures, and the subtle differences in their consistency models.