What is 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.

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 5-node cluster, three nodes must be online to have a majority.
• In a 4-node cluster, three nodes must be online to have a majority.
• With 5-node, the system can afford two node failures, whereas, with 4-node, it can afford only one node failure. Odd cluster sizes are common because they avoid tie votes in pure majority systems, but tunable quorums (R+W>N) work with even N too. The real design question is how many simultaneous failures you must survive.

Majority is the common case, not the only quorum. A majority (more than half) is the most common quorum because it is easy to reason about, but it is not the only one. The general rule is R + W > N: any read quorum and any write quorum drawn from the same N replicas must share at least one replica. For example, with N = 5 you could set W = 2 and R = 4; the write needs only two acks, the read queries four replicas, and R + W = 6 > 5 guarantees overlap. This tunability is what lets systems trade write latency against read latency.

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. For example, a common configuration could be (N=3, W=2, R=2) to guarantee that every read overlaps the latest acknowledged write (read freshness — see the two-inequalities section below for why this is weaker than linearizability). 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

Two inequalities, not one

The rule R + W > N guarantees that any read quorum and any write quorum overlap, so a read always sees the latest acknowledged write. This buys freshness — a read is guaranteed to touch a replica holding the latest committed value — but not full linearizability: while a write is still in flight (not yet acked by W replicas), two back-to-back reads can hit different subsets and disagree, so overlap alone does not give a real-time total order. There is a second, independent rule: W > N/2. It guarantees that any two write quorums also overlap. Without it, two concurrent writes could each succeed on disjoint replica sets and the system would have no shared replica to detect the conflict.

Trace the difference with N = 4. If W = 2, write 1 can be acknowledged by replicas {A, B} while write 2 is acknowledged by {C, D}. The two write sets are disjoint, so both writes can claim success with no overlap to resolve the conflict. If W = 3, any two size-3 subsets of a 4-node cluster must share at least two replicas, so a conflict is always visible to at least one node. The same pigeonhole principle powers both rules.

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.
• Best performance (throughput/availability) when , because reads are more frequent than writes in most applications

Caution: 1 < r < w < n is a latency-shaping heuristic, not a correctness rule — it does not by itself guarantee R + W > N. Check: n=5, r=2, w=3 satisfies 1 < 2 < 3 < 5, yet R + W = 5, which is not greater than N = 5, so a read set {D, E} and a write set {A, B, C} can be disjoint. Pick R and W from the overlap rule first, then shape latency within it.

How It Works

• Majority-Based Quorum: The most common type of quorum where an operation requires a majority (more than half) of the nodes to agree or participate. For instance, in a system with 5 nodes, at least 3 must agree for a decision to be made.
• Read and Write Quorums: For read and write operations, different quorum sizes can be defined. For example, a system might require a write quorum of 3 nodes and a read quorum of 2 nodes in a 5-node cluster.

Use Cases

Distributed Databases

• Ensuring consistency in a database cluster, where multiple nodes might hold copies of the same data.

Cluster Management

• In server clusters, a quorum decides which nodes form the 'active' cluster, especially important for avoiding 'split-brain' scenarios where a cluster might be divided into two parts, each believing it is the active cluster.

Consensus Protocols

• In algorithms like Paxos or Raft, a quorum is crucial for achieving consensus among distributed nodes regarding the state of the system or the outcome of an operation.

What you buy / what you pay

What a quorum buys: the system keeps operating with a minority of replicas down, and per-key read freshness without appointing any single node the sole authority. What it charges: every operation now waits on multiple nodes, so latency tracks the slowest replica you are required to hear from; a partition can make a quorum unformable, stalling the minority side by design; and membership churn (nodes joining, leaving, failing mid-write) makes the bookkeeping genuinely complex. The sections below price these trades concretely.

Majority quorum math

For a cluster of N nodes, a strict majority quorum requires ⌊N/2⌋ + 1 nodes. This formula guarantees that two different quorums cannot be formed from disjoint subsets of nodes:

• N=3: majority = 2 nodes; can tolerate 1 failure.
• N=5: majority = 3 nodes; can tolerate 2 failures.
• N=4: majority = 3 nodes; can tolerate only 1 failure.

This is why odd cluster sizes are preferred for pure majority systems: a 5-node cluster tolerates two failures while a 4-node cluster tolerates only one, yet both require three nodes for a quorum.

Minority partition behavior

When a network partition splits the cluster, the minority side cannot form a quorum and must stop processing writes. The majority side continues. This rule prevents two partitions from diverging independently.

Example: a 5-node cluster partitions into {A, B, C} (3 nodes) and {D, E} (2 nodes). Only the 3-node partition can accept writes. The 2-node partition either rejects writes or serves stale reads, depending on configuration. If both sides accepted writes, reconciliation after the partition healed would require conflict resolution.

Quorum in Raft, Paxos, and Dynamo

The difference is instructive. Raft and Paxos use majority to guarantee a single coherent log; Dynamo uses tunable quorums to let operators pick their own latency/durability point. Both prevent split brain, but Raft does so through a single leader and majority votes, while Dynamo does so through version vectors and read repair.

Split-brain prevention

Split brain occurs when two partitions of a cluster both believe they are authoritative and accept conflicting writes. Quorum-based systems prevent this by requiring a majority for any state-changing decision.

The argument is simple: if a majority is required, at most one partition can hold a majority at any time. A cluster of 5 nodes cannot split into two groups of 3; one group must have at most 2 nodes and therefore cannot write. In leader-based systems (Raft, Paxos) the leader must also hold a majority lease or term vote, so two leaders cannot exist simultaneously.

When a quorum is the wrong tool

A quorum is a per-key freshness-and-availability mechanism, not a universal consistency hammer. Three situations should push you toward a different primitive.

1. Multi-key or global invariants. R + W > N guarantees a read of one key sees that key's latest write. It says nothing across keys. "Debit account A and credit account B atomically," or "total seats sold ≤ 100," cannot be expressed by a quorum on individual keys — no per-key overlap rule can enforce a constraint that spans keys. That is the job of a single-leader store with real transactions, or a consensus log (Raft/Paxos) that serializes the conflicting operations. Reach for a quorum when keys are independent; reach for a leader or consensus when a write must be validated against other keys before it commits.

2. Fresh reads that dominate the workload. A strongly-consistent quorum read must contact R replicas on every read and take the newest version, so the cluster does R× the client read rate in internal work. At R=2 that is 2× read-amplification: a service taking 600K client reads/s pushes 600K × 2 = 1.2M internal replica reads/s just to satisfy the overlap rule. A single leader holding a read lease answers a fresh read from one node with zero cross-replica fan-out — 1× — because the lease guarantees no other node holds a newer committed value for the lease window. When reads dominate and must be fresh, a leased leader (plus async read replicas for scale) beats a quorum read; a quorum earns its R× cost when writes are frequent and no single node may be trusted as the sole authority.

3. Strict availability under partition. A strict quorum stops the minority side: on N=3, W=2, losing 2 of the 3 preferred replicas makes writes impossible — you cannot collect two acks. A sloppy quorum keeps writing by accepting the write on fallback nodes (hinted handoff), trading a bounded staleness window — reads from the original replicas miss the write until the hints drain — for continued availability. The crossover is a policy choice, not a tuning knob: "never reject a write, tolerate seconds-to-minutes of staleness" ⇒ sloppy; "never serve a stale read, rejecting under partition is acceptable" ⇒ strict. The mechanics of hinted handoff and its staleness window live on the dedicated Failure Under Scale page; the overlap-rule arithmetic is on Quorum Arithmetic and Quorum in Practice.

Interactive walkthrough

Step through the mechanism, predict each fork, and watch the state change.