Quorum: How Distributed Systems Agree Without Unanimity

WHY IT EXISTS In a distributed system, nodes can fail or become unreachable. If you require all nodes to agree on an operation (unanimity), a single slow or failed node can halt the entire system. Quorum was created to solve this by enabling a system to make durable, consistent decisions without depending on every single member.

THE MENTAL MODEL Think of a board of directors with 11 members. A decision requires a simple majority of 6 votes. You don't need all 11 to be present or agree; as long as you get 6 votes, the decision is binding. This ensures that even if 5 members are unreachable, the board can still function. Crucially, two different conflicting decisions cannot both get 6 votes, because that would require 12 total votes from an 11-member board. This principle of overlapping majorities is what guarantees consistency.

HOW IT WORKS A quorum is the minimum number of nodes that must acknowledge an operation before it's considered successful. For a system with N nodes, you might define a write quorum (W) and a read quorum (R). To guarantee that a read operation can find the result of the most recent write, the numbers must satisfy the rule: W + R > N. For example, in a 5-node system (N=5), you could set W=3 and R=3. A write must succeed on 3 nodes. Any subsequent read from any 3 nodes is guaranteed to overlap with the write set by at least one node (3+3 > 5), ensuring the reader sees the latest data.

WHEN TO USE IT Use quorum whenever you need both high availability and strong consistency in a distributed system. It is the standard mechanism for state machine replication, leader election in consensus algorithms like Raft, and ensuring durable writes in distributed databases like Cassandra, DynamoDB, and Riak.

WHEN NOT TO USE IT Quorum is overkill if your system can tolerate eventual consistency and prioritizes raw performance and availability above all else. Simpler, faster replication schemes (like 'write to one, read from one') exist but do not provide the same consistency guarantees. The concept is also irrelevant for single-node systems, as it is a solution for multi-node coordination problems.

ONE CANONICAL EXAMPLE A 5-node database cluster uses a write quorum of 3. When a client sends a write request, a coordinator node forwards it to all 5 replicas. The coordinator waits. As soon as it receives acknowledgements from any 3 of the 5 nodes, it considers the write successful and confirms it to the client. The remaining 2 nodes can receive the update later. This configuration ensures the write is durable even if up to 2 nodes fail.