The databases track showed how one primary streams to replicas. This lesson is about the shapes above that: single-leader, multi-leader, and leaderless replication, and the trade each makes. It then works through the quorum arithmetic that leaderless systems (Dynamo, Cassandra) run on — the R + W > N rule that lets you dial consistency against availability with two numbers — including why it's a probabilistic promise, not the linearizable guarantee people assume, and how sloppy quorums and hinted handoff bend it further for availability.

Replication topologies & quorums

The replication lesson covered the mechanics of copying data between nodes and assumed one specific shape: a single primary that accepts all writes and streams them to read-only replicas. That's the most common topology, but it's one of three, and the choice among them is a direct consequence of the CAP and consistency trade-offs. Each topology answers "who is allowed to accept a write?" differently, and everything else follows.

Single-leader: one writer, simple truth

Single-leader (primary/replica) replication designates exactly one node that accepts writes; it propagates them to replicas that serve reads. This is Postgres streaming replication, MySQL, most managed relational databases.

Its great virtue is there is always one authoritative order of writes — the leader decides it — so there are no write conflicts to resolve, ever. Two clients writing the same row are serialized by the single leader. That simplicity is why it's the default, and why a single-leader system can offer strong consistency for reads routed to the leader.

Its limits are equally clear: the leader is a write bottleneck (all writes funnel through one node — replication scales reads, not writes, which is why you eventually shard), and it's a failure point requiring failover with all its split-brain hazards. One writer is simple and a ceiling.

Multi-leader: write anywhere, reconcile later

Multi-leader replication allows several nodes to accept writes, each replicating to the others. The usual reason is geography: a leader in each region, so users write to a nearby one with low latency, and the regions sync asynchronously. (Offline-capable apps are the same shape — each device is a "leader" that accepts writes offline and syncs later.)

The payoff is write availability and low write latency everywhere — no cross-region round trip to a single leader, and writes continue during a partition. The price is the thing single-leader never has: write conflicts. Two leaders can accept conflicting writes to the same data concurrently (you edit a group's name in Mumbai while your co-organizer edits it in London), and when those replicate to each other, the system must resolve the conflict — which is the entire next lesson. Multi-leader buys availability with the permanent tax of conflict resolution.

Leaderless: quorums instead of leaders

Leaderless replication (the Dynamo design, used by Cassandra, Riak, DynamoDB) throws out the leader entirely. The client (or a coordinator on its behalf) writes to many replicas at once and reads from many at once, and consistency emerges from how many it insists on hearing from — the quorum. There's no failover because there's no leader to fail; any node can take any request.

This is the most available design, and it runs on arithmetic worth understanding, because the same quorum idea appears in consensus systems, distributed locks, and anywhere a group of nodes must agree.

The quorum rule: R + W > N

Let:

N = the number of replicas each piece of data is stored on.
W = the number of replicas that must acknowledge a write before it's considered successful.
R = the number of replicas that must respond to a read before it returns.

The central rule is:

If R + W > N, then any read set and any write set must overlap in at least one node — so a read is guaranteed to contact at least one replica that has the latest write.

That overlap is the whole trick. With N = 3, choosing W = 2 and R = 2 gives R + W = 4 > 3, so the two nodes you read from and the two you wrote to must share at least one node — and that shared node has the fresh value. Tuning the three numbers dials the trade-off directly:

Drag R and W and watch the overlap appear and vanish. While R + W > N there's always a node in both sets (outlined) — the read is guaranteed fresh. Pull them down until R + W ≤ N and the sets separate: now a read can hit only stale replicas.

Replicas (N)

Write quorum W = 2

Read quorum R = 2

R1W

R2W

R4R

R5R

2 + 2R + W

possible staleread may miss the write

The whole rule is R + W > N: when it holds, any read set and any write set must share at least one replica — the one in both columns above, which carries the fresh value, so a read is guaranteed to see the latest write. Drop R or W until R + W ≤ N and the sets can miss each other: a read might hit only stale replicas. Smaller R/W means lower latency and more failures tolerated but weaker consistency; larger means the opposite. Two knobs place you on the whole consistency-vs-availability spectrum.

W = N, R = 1 — writes must hit every replica; reads ask just one. Fast, consistent reads; writes are slow and fragile (one replica down blocks all writes). Good for read-heavy, write-rare data.
W = 1, R = N — write to one, read from all. Fast, available writes; slow reads. Good for write-heavy data.
W = 2, R = 2, N = 3 — the balanced default: tolerate one node down for both reads and writes, still overlap. This is the classic quorum.

Smaller W and R mean lower latency and higher availability (fewer nodes to wait for, more failures tolerated) but weaker consistency; larger means the opposite. Two numbers, and you've placed yourself on the PACELC spectrum.

A quorum is not linearizability — the guarantee is weaker than the arithmetic suggests

It is dangerously easy to read "R + W > N guarantees you read the latest write" and conclude quorums give you strong consistency. They do not, and betting on it causes real bugs. The overlap guarantees a read contacts a node with the latest value — but several real conditions break the clean promise. Concurrent writes: if two writes happen at once, the quorum doesn't decide which "wins" — that's left to conflict resolution (usually last-write-wins by timestamp, which can silently drop one of the writes; see the next lesson). Partial writes: a write that reached only some of its W replicas before the client crashed leaves the value in a nondeterministic state — some later reads see it, some don't. Read repair timing and clock skew further blur it. And crucially, most real deployments use sloppy quorums: to stay available when the "home" replicas for a key are unreachable, the system writes to whatever N nodes it can reach (with hinted handoff — a stand-in node holds the write and forwards it to the rightful owner once it's back). That keeps writes flowing during a partition, but it means the W nodes that accepted a write and the R nodes a later read consults may not overlap at all, so the "R + W > N" guarantee is temporarily void — by design, trading consistency for availability exactly as an AP system should. The takeaway: quorums give you a tunable, probabilistic freshness that's excellent for AP systems, but if you need genuine linearizability you need a real consensus protocol (Raft/Paxos), not quorum arithmetic. Knowing the difference is what separates "we set R=W=2, so we're consistent" (wrong) from "we're eventually consistent with a high probability of freshness, and we resolve conflicts explicitly" (right).

Where this lives in Fable

Fable uses none of the multi-node topologies — and this lesson is largely the argument for why that restraint is correct at its scale. The ledger is single-leader with exactly one node: one writer, one authoritative order of writes, zero write conflicts to resolve — the simplicity that makes a money app tractable. Choosing leaderless quorums for a balance ledger would be actively wrong: the "R + W > N is not linearizability" trap above is precisely the kind of subtle staleness a ledger cannot tolerate, and the conflict-resolution tax of multi-leader buys availability Fable doesn't need for a single-region product. Two honest connections, though. First, the concept of a quorum already governs Fable's future: the day it enables a Cloud SQL high-availability standby, that standby is a synchronous replica the primary waits on before acking — effectively W = 2 for durability, a quorum of two, chosen for the CP guarantee that no acknowledged write is lost on failover. Second, multi-leader is the shape a truly offline-first mobile app takes — each phone accepting edits offline and syncing later is multi-leader replication with the device as a leader, and it would drag in exactly the conflict resolution of the next lesson. Fable avoids that by treating the server as the single source of truth and keeping the client a cache, not a leader — a deliberate choice to not sign up for conflict resolution. The whole topology story for Fable is "stay single-leader as long as humanly possible, because single-leader is the one shape with no conflicts."

Go deeper

DeCandia et al. — "Dynamo: Amazon's Highly Available Key-value Store" (2007) — The paper that defined leaderless replication, tunable N/R/W quorums, sloppy quorums, and hinted handoff — every idea in the quorum half of this lesson, from the source.
Kleppmann — Designing Data-Intensive Applications, ch. 5 — The definitive walk through single-leader, multi-leader, and leaderless topologies and where each fits — with the conflict and quorum edge cases laid out carefully.
Jepsen — Cassandra analysis — A concrete, adversarial look at what quorum consistency actually delivers under partition in a real leaderless database — the "quorum ≠ linearizable" callout, demonstrated.

Check yourself

Answer out loud, as if an interviewer asked. If you hand-wave, reread that section.

Explain why single-leader replication has no write conflicts, and name the two ceilings it hits in return (the one that pushes you to shard, and the one that needs failover).
Multi-leader replication buys something single-leader cannot, at a specific cost. State both, and give a concrete scenario (geographic or offline) where multi-leader is the natural fit.
Define N, R, and W, and explain why R + W > N guarantees a read set and write set overlap. Give the tunings for read-optimized, write-optimized, and balanced, and what each sacrifices.
Someone concludes "we run R = W = 2 with N = 3, so our reads are linearizable." Give two distinct reasons that's wrong (think concurrent writes and sloppy quorums).
What problem do sloppy quorums and hinted handoff solve, and what guarantee do they temporarily void to solve it? Why is that an acceptable trade for an AP system?
Fable stays single-leader on purpose. Explain why leaderless quorums would be the wrong choice for a balance ledger, and how an offline-first mobile client would turn the app into a multi-leader system whether you wanted it or not.

Replication topologies & quorums

Replication topologies & quorums

Single-leader: one writer, simple truth

Multi-leader: write anywhere, reconcile later

Leaderless: quorums instead of leaders

The quorum rule: R + W > N

Go deeper

Check yourself

On this page