Single-leader and multi-leader both route writes through special nodes — and special nodes fail specially: elections, failovers, fencing. The Dynamo lineage (Amazon's Dynamo paper → Cassandra, Riak, ScyllaDB, Voldemort) asks a radical question: what if no node is special? The client (or a coordinator acting for it) sends every write to all N replicas in parallel, and correctness comes not from hierarchy but from counting.
The whole protocol fits in three symbols. With N replicas per key: a write succeeds once W replicas confirm; a read queries R replicas and takes the newest version among the answers. The law of the land: if W + R > N, every read set must overlap every write set in at least one node — so at least one consulted replica always holds the latest write, and version numbers pick it out.
Feel the inequality
Tune the quorum
N = 3. Slide W and R, then run write → read repeatedly. Green rings = replicas the write reached; amber rings = replicas the read consulted. When the inequality fails, staleness isn't guaranteed — it's a dice roll. Roll it enough times.
runs
0
fresh reads
0
stale reads
0
The knobs are per request in Cassandra (consistency levels ONE, QUORUM, ALL...): the same table can take fire-and-forget telemetry writes at W=1 and serve balance checks at R=QUORUM. Common recipes: N=3, W=2, R=2 balanced; W=N, R=1 for read-heavy data; W=1, R=N for write-heavy. Lower W and R buy latency and availability — the request completes as soon as the fastest W (or R) nodes answer, so slow nodes stop mattering. That tail-latency immunity is a headline reason Dynamo-style systems exist.
Strict quorums have a failure mode: with N=3, W=2 and one replica down, writes still work — but with two down (or a partition hiding them), writes for those keys stop. Dynamo-style systems offer a trade: a sloppy quorum accepts the write on substitute nodes outside the key's home set, each carrying a hint — "this belongs to node B; deliver when it returns." Availability preserved; the W+R overlap guarantee temporarily suspended.
Break a node, keep writing
Key "cart:alex" homes on nodes A, B, C; node D is a neighbor. Click nodes to fail them. Write with W=2 in strict vs sloppy mode, then revive the dead node and deliver the hints.
Convergence: read repair & anti-entropy
With no leader streaming a log, how do stale replicas ever catch up? Two mechanisms. Read repair: when a read consults R replicas and their versions disagree, the coordinator returns the newest — and writes it back to the stale replicas it just caught, in the background. Hot data heals itself simply by being read. Anti-entropy: a background process continuously compares replicas (using Merkle trees to avoid comparing every key) and syncs differences — the safety net for cold data nobody reads.
Watch a read heal the cluster
Node C missed the last write and holds v1 while A and B hold v2. Run a read with R=2 until it happens to include C — and watch the repair.
What leaderless gives up: there is no ordering authority, so there are no transactions across keys, and concurrent writes to the same key produce the same sibling/LWW dilemmas as multi-leader (Dynamo-style systems use version vectors to at least detect concurrency). What it gains: no failover, ever — a node dying is an ordinary Tuesday handled by arithmetic, not an emergency handled by an election. For always-writable, partition-tolerant workloads at scale — carts, sessions, time-series, feeds — that trade wins.
Check yourself
1. N=3, W=1, R=1. What is the honest description of this configuration?
1+1 ≤ 3: no overlap guarantee, as the first lab demonstrated statistically. It's a legitimate, popular choice (Cassandra ONE/ONE) for data where speed beats freshness — telemetry, likes, view counters. The system still converges eventually via read repair and anti-entropy; it just promises nothing about when.
2. During a sloppy-quorum window (hints on substitute nodes, not yet delivered), what does W+R>N guarantee?
The overlap proof assumes reads and writes draw from the same N-node home set. A sloppy write on substitute D isn't in that set, so a perfectly legal quorum read of {A, C} sees the past. Sloppy quorums trade the durability of the guarantee for availability — which is why they're a config flag, not a default truth.
3. Why do anti-entropy processes compare Merkle trees instead of the data itself?
Each node hashes ranges of its keyspace into a tree; two replicas compare root hashes, and only descend into subtrees that differ. Identical data = one hash comparison. A single divergent key = a logarithmic walk to find it. Same trick, incidentally, that git and blockchains use for the same reason.