Quorums

An online shop keeps every shopping cart on three servers, called replicas, so a cart survives a dead server. There is no leader: any replica can take a write. That keeps the cart writable even while one server is down, which matters, because a cart that refuses an item is a lost sale.

Now follow one cart. You add a lamp. The write reaches replicas A and B, but C is restarting and misses it. A minute later the app reads your cart from C alone:

The two obvious fixes both hurt:

• Write to all three, read from any one. Reads are always current, but a single dead replica stops every write.
• Write to any one, read from all three. Writes never stop, but a single dead replica stops every read.

A quorum sits between them: wait for some of the replicas on each side, chosen so that the two sides always meet.

Three numbers describe a quorum system:

• N, the number of replicas of each item.
• W, how many must confirm a write before it counts as done.
• R, how many must answer a read.

The rule is W + R > N. With N = 3, W = 2 and R = 2, the write lands on two replicas and the read asks two. Two plus two is four, but there are only three replicas, so at least one replica must be in both groups. That replica has the lamp.

The read gets two answers that may disagree, so each value carries a version, such as a counter or a timestamp, and the reader keeps the newest. Here is how the dial turns for N = 3:

A majority quorum is the common default: ⌊N ÷ 2⌋ + 1 replicas, which is 2 of 3 or 3 of 5. Using it on both sides gives overlap and survives the loss of a minority. It is the same arithmetic that consensus protocols rely on (Consensus & leader election), applied here to reads and writes instead of to decisions.

The setting is often chosen per request rather than once per database. Cassandra calls these choices consistency levels: ONE, QUORUM and ALL, among others. The original Dynamo design, built at Amazon for exactly this kind of shopping cart, most commonly ran N = 3, R = 2, W = 2.

Availability follows from the same numbers. Say each replica is down 1% of the time, independently of the others:

Waiting for all three is a hundred times worse than a quorum. Independence is the caveat that makes the table true: three replicas in one rack, on one power feed, fail together (Redundancy & failure domains).

The coordinator sends a read to all three replicas at once and answers as soon as R of them reply. So a read's time is set by the R-th fastest replica, and a single slow replica is simply ignored. Say two replicas answer in 4 ms and 6 ms, and the third is in the middle of a long garbage-collection pause:

This is a quiet advantage over a single leader. With one leader, every write waits for that one machine, however slow it is right now. A quorum lets the fastest replicas carry each request, which cuts the tail of the latency curve.

Replica C still has the old cart. Quorums tolerate that, but if nothing fixes C, a later failure of A or B leaves the lamp on only one replica. Three mechanisms bring stragglers up to date:

Read repair only fixes what people read, and hints are kept for a limited window: Cassandra keeps them for 3 hours by default. Both are best effort. Anti-entropy is the backstop, and it needs a cheap way to compare millions of rows between two servers without sending them all.

The tool is a Merkle tree: each leaf is a hash of a range of rows, and each parent is a hash of its children. Two replicas compare their roots. If the roots match, everything matches. If not, they compare the children and follow only the branches that differ:

One more relaxation is worth knowing. In a sloppy quorum, used by the original Dynamo, a write that can't reach its usual replicas is accepted by other healthy nodes and handed back later. Writes keep working through bigger failures, but the write may now sit on nodes that a read never asks, so W + R > N no longer guarantees overlap.

W + R > N promises that a read overlaps the latest completed write. It does not make the replicas behave like a single copy (Consistency models calls that linearizable). The gaps show up in specific moments:

A read during a write. The new value has reached A but not yet B or C. One reader asks A and C and sees the new value; a moment later another reader asks B and C and sees the old one. Two people, one after the other, see time run backwards:

Concurrent writes. Two devices change the cart in the same instant. If the newest timestamp simply wins (last write wins), one change is silently lost, and a clock that runs fast can make the older write the winner. Dynamo kept both versions instead and let the cart merge them; in its measurements, 99.94% of requests saw exactly one version.

Two more gaps:

• A failed write that half happened. It reached one replica, not two, and was reported as failed. It is not rolled back, so later reads may or may not show it.
• A replica restored from an older copy. The new value may now be on fewer than W replicas.

Two fixes exist for when you need more. A read can write back the newest value to a quorum before answering, which costs a second round trip. And an operation like reserve the last item only if it is still in stock needs real consensus, which Cassandra offers as lightweight transactions. Use them for the few operations that need them, not for every cart update.

The shop now runs in two regions, each with three replicas of every cart: six in all. A plain majority of six is four, so every quorum write must reach at least one replica across the ocean and waits for that round trip. Losing the link between regions stops quorum writes in both.

LOCAL_QUORUM is the usual choice. Reads and writes in the same region overlap, and a region keeps working when the other is unreachable. The price: a cart written in Europe and read in America a moment later may not show the change yet. For a cart, a user is almost always served by one region, so that is acceptable; for an account balance it might not be.

This is the CAP trade-off in practice (CAP & PACELC). During a partition, the side that can't reach its quorum must refuse requests, and the side that can keeps going. Choosing the level per request chooses, per request, which way to fall.