Quorum

Pradeep P
3 days ago
3 min read

Series: Modern System Design · Layer 3 — Reliability

Layer 3 · Post 12 of 14

← Previous: Leader Election → Next: CAP Theorem

Layer 3 — Reliability · Post 37 of 88

A quorum is the minimum number of nodes that must agree before a decision sticks. It is how clusters stay correct when some nodes are gone.

What you'll learn

Majority quorums: why 3 and 5 nodes, and why 2 is a trap
Read/write quorums (R + W > N) so two sides of a split cannot both commit
What you give up: a minority partition cannot make progress (that is CAP, next)

The idea in one minute

A quorum is "enough nodes." For majority, enough is floor(N/2) + 1.

3 nodes: quorum = 2 5 nodes: quorum = 3

Leader election (previous) needs a quorum of votes. A write in a replicated store may need a quorum of disks. The rule you are buying: two disjoint groups cannot both think they won, because they cannot both hold a majority of the same N.

Partition: {A, B} | {C} N=3: {A,B} has 2 --> can elect / commit {C} has 1 --> cannot

Why it matters

Without a quorum rule, "any node that cannot see the others becomes leader" is split-brain. With it, the minority stops. That looks like downtime on that side — and it is the correct downtime. You chose not to diverge.

Interviews: they will ask how many failures you can survive. Answer: a majority quorum of 2f+1 nodes survives f failures (3 survives 1, 5 survives 2). They will also ask about even cluster size (4 nodes, majority 3: you survive 1, but 2 vs 2 is stuck). Odd N is the default.

How it works

Strict majority (Raft, etcd, ZooKeeper). Commits and elections need a majority. The leader is in the majority (or it is not leader). Disk loss of one node in a 3-node cluster: still 2, still live.

Dynamo-style R, W, N. N replicas, write waits for W, read waits for R. If R + W > N, some replica in the read set saw the last write (assuming no bit flips). Example: N=3, W=2, R=2. You can survive one node down for writes (two still up). R=1, W=1 is fast and can miss writes — eventual consistency (Post 39).

Don't require all N. W=N is "every replica," which is high durability until one node is slow — then writes stall. Quorum is the usual compromise.

Witnesses / tie-breakers. A tiny third voter (some SAN / cloud quorum blob) so two data nodes can still form a majority. Same math, cheaper third node.

Quorum is about agreement, not "everyone is healthy." A node can be up but lagging; Kafka's ISR is a qualified replica set you take quorum from, not random stale disks.

A simple example

etcd with three AZs, one node each. AZ1 burns. Two nodes remain: they still have quorum, Kubernetes API keeps working. If you had two nodes total, losing one means the survivor must not elect itself (majority of 2 is 2). The cluster is read-only or down until you intervene. That is why people run 3.

Cassandra: N=3, QUORUM (W=2, R=2). One node down, reads and writes still meet. ONE (R=1,W=1) stays up more often and can return old values. You picked AP vs CP-ish behavior before the CAP lecture.

Common mistakes

Two-node "HA." No majority that survives one loss without split-brain risk. Add a witness or a third node.

Quorum across two DCs only (2 and 2). A DC split is 2 vs 2: no majority. Odd number of DCs, or a tie-breaker region.

R + W ≤ N and then claiming strong reads. You did not overlap.

Counting dead or lagging replicas as voters without ISR/sync rules. You "committed" to a node that never got the bytes.

Growing N without changing the mental model. Five nodes survive two failures and write slower (more ack paths). That is a product choice.

How this shows up in real systems

etcd, ZooKeeper, Consul, Raft: majority votes.
Cassandra / DynamoDB / Riak: tunable R and W.
Kafka min.insync.replicas + acks: a quorum of in-sync replicas, not merely of brokers.
MongoDB replica set majority write concern; Elasticsearch minimum_master_nodes (older) / voting config.