Replication and Consistency Models

Partitioning and Sharding splits different data across nodes to scale. Replication solves a different problem: keeping copies of the same data on multiple nodes, so losing one machine does not lose the data, and so more than one machine can serve reads for it. Real systems combine both — each partition is itself replicated across several nodes.

Leader-based replication#

The most common shape: one node per partition is the leader, accepting all writes; the rest are followers, replicating from it:

Client --- write ---> Leader                          |              replicates to followers                    /              \              Follower A       Follower B

The open question is when the leader considers a write done. Synchronous replication waits for one or more followers to confirm before acknowledging the client — stronger durability, higher latency, and the write blocks if a required follower is unreachable. Asynchronous replication acknowledges immediately and replicates in the background — lower latency, but a leader that fails right after acknowledging a write can take that write down with it, before any follower ever received it.

Quorum-based replication#

An alternative, used by Dynamo-style systems, has no fixed leader at all: any replica can accept a write, and both reads and writes are sent to multiple replicas at once, with success requiring a quorum — a minimum number of nodes to agree:

N = 3 replicas totalW = 2 replicas must acknowledge a writeR = 2 replicas must respond to a read
Because W + R > N (2 + 2 > 3), every read overlaps withevery write by at least one replica — guaranteeing the readsees at least one copy of the latest write.

This W + R > N relationship, described in Amazon's Dynamo paper, is what gives a quorum-based system its consistency guarantee without ever needing a single leader — tunable per operation, at the cost of needing to reconcile the rare case where concurrent writes to different replicas genuinely conflict.

The consistency spectrum this produces#

• Strong consistency (also called linearizability) — every read reflects the most recent acknowledged write, from every replica, every time. Synchronous leader-based replication with reads always routed through the leader can provide this; it is the most expensive guarantee to maintain under load.
• Eventual consistency — replicas are allowed to disagree temporarily, with a guarantee that they converge given no further writes, but no guarantee on how long convergence takes. Asynchronous replication and under-quorum reads both land here.
• Read-your-writes / session consistency — a practical middle ground: a client is guaranteed to see its own writes immediately (often by routing its own subsequent reads through the same replica or the leader), while other clients might still observe a stale value briefly.

Every one of these is a legitimate design choice, not a hierarchy where higher is always better — strong consistency costs latency and availability during a partition, exactly as The CAP Theorem describes, and eventual consistency is the right trade for workloads that value staying available over every reader seeing the same value at the same instant.

Common mistakes#

Treating replication as a backup#

Replication protects against a node dying, not against a bad write. A corrupted or accidentally deleted row replicates to every follower just as faithfully as a correct one — replication and backup solve different failure modes and are not substitutes for each other.

Reading from a follower and assuming it is current#

Under asynchronous replication, a follower can be seconds — or, under load, much longer — behind the leader. Read-after-write logic that silently reads from a random follower will intermittently "lose" a write that, in fact, succeeded and is simply still propagating.

Assuming quorum overlap alone prevents every conflict#

W + R > N guarantees a read overlaps with the most recent acknowledged write in the normal case. It does not, by itself, resolve two clients writing to different replicas concurrently — that reconciliation is a separate mechanism most quorum-based systems still need on top.

Further reading#

• Replication (computing) — the general concept, spanning databases, file systems, and beyond.
• Dynamo: Amazon's Highly Available Key-value Store — the paper behind the quorum model described above.
• Quorum (distributed computing) — the formal definition of the W + R > N guarantee.
• Strong consistency and Eventual consistency — the two ends of the spectrum this article covers.

See also#