Quorum

Background

In Distributed Systems, data is replicated across multiple servers for fault tolerance and high availability. Once a system decides to maintain multiple copies of data, another problem arises: how to make sure that all replicas are consistent, i.e., if they all have the latest copy of the data and that all clients see the same view of the data?

Solution

In a distributed environment, a quorum is the minimum number of servers on which a distributed operation needs to be performed successfully before declaring the operation's overall success.

Suppose a database is replicated on five machines. In that case, quorum refers to the minimum number of machines that perform the same action (commit or abort) for a given transaction in order to decide the final operation for that transaction. So, in a set of 5 machines, three machines form the majority quorum, and if they agree, we will commit that operation. Quorum enforces the consistency requirement needed for distributed operations.

Building-blocks overview / on-ramp. This page introduces the idea. For the full treatment — the pigeonhole proof of R + W > N, the second inequality W > N/2, conflict resolution (read-repair, anti-entropy), and strict vs. sloppy quorums with hinted handoff — study What is Quorum and Quorum Arithmetic — Why R + W > N.

In systems with multiple replicas, there is a possibility that the user reads inconsistent data. For example, when there are three replicas, R1, R2, and R3 in a cluster, and a user writes value v1 to replica R1. Then another user reads from replica R2 or R3 which are still behind R1 and thus will not have the value v1, so the second user will not get the consistent state of data.

What value should we choose for a quorum? More than half of the number of nodes in the cluster: where is the total number of nodes in the cluster, for example:

• In a 4-node cluster, three nodes must also be online to have a majority (more than half of 4 is 3) — the same quorum size as the 5-node example above.
• So a 5-node cluster can afford two node failures, whereas a 4-node cluster can afford only one node failure. Because of this logic, it is recommended to always have an odd number of total nodes in the cluster.

Quorum is achieved when nodes follow the below protocol: , where:
= nodes in the quorum group
= minimum write nodes
= minimum read nodes

If a distributed system follows rule, then every read will see at least one copy of the latest value written. Why it works: the write was acknowledged by W nodes and your read asks R nodes; since W + R > N, two subsets of an N-node pool that together exceed N members must share at least (W+R)−N ≥ 1 node — so at least one node you read holds the latest acknowledged write. For example, a common configuration is (N=3, W=2, R=2), which guarantees every read quorum overlaps the ack-set of the last completed write — the read-sees-latest-completed-write guarantee. Note that this is weaker than strong consistency/linearizability: while a write is still in flight, or after a partially-failed write, different readers can disagree — see Quorum is not Linearizability for the failure trace. Here are a couple of other examples:

• (N=3, W=1, R=3): fast write, slow read, not very durable
• (N=3, W=3, R=1): slow write, fast read, durable

The following two things should be kept in mind before deciding read/write quorum:

• R=1 and W=N ⇒ full replication (write-all, read-one): undesirable when servers can be unavailable because writes are not guaranteed to complete.
• Tune within the overlap constraint: choose r and w with r + w > n first (that is the overlap guarantee), then bias within it: read-heavy systems minimize r subject to r + w > n and take a large w (e.g. n=5, r=2, w=4); write-heavy systems do the reverse (e.g. n=5, w=2, r=4). Beware the naked performance rule (often quoted because reads are more frequent than writes): it admits configurations that break the overlap. Counterexample: n=5, r=2, w=3 satisfies 1 < r < w < n, yet r + w = 5 = n, not > n — a write acknowledged by nodes {A, B, C} can be answered by a read quorum {D, E} that is completely disjoint from it, so the read misses the latest write entirely.

When quorum alone is the wrong tool: if you need ordered writes or transactions, quorum reads and writes by themselves do not provide them — use leader-based replication, where a single leader sequences every write (see Leader and Follower). Quorum reads also pay the latency of the slowest of the R nodes contacted, so tail latency grows with R.

Where Quorums Are Used

• Distributed databases: Dynamo-style stores (Cassandra, Riak) apply per-key read/write quorums so that, with r + w > n, a read quorum always intersects the ack-set of the last completed write across replicas of the same data.
• Cluster management: a quorum decides which nodes form the 'active' cluster, avoiding 'split-brain' scenarios where a partitioned cluster divides into two parts, each believing it is the active cluster — only the side holding a majority may act, and since two majorities of the same cluster must intersect, at most one side can ever hold one.
• Consensus protocols: Paxos and Raft commit a value only once a majority accepts it; because any two majorities intersect, a newly elected leader is guaranteed to see every previously committed entry.

The honest trade-off: during a network partition, quorum keeps the majority side consistent and writable at the cost of the minority side's availability — nodes cut off from a majority must refuse quorum operations until the partition heals. That refusal is not a defect; it is the price paid so the system never serves two divergent views of the data.

I just read a lesson on **Quorum** (System Design) and want to truly understand it. Explain Quorum from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **Quorum** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **Quorum** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **Quorum** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.