Replication

Replication is usually introduced as "for availability", as though availability were one thing. There are four distinct motives, they want four different protocols, and choosing the protocol before naming the motive is how teams end up paying multi-region coordination costs for a read-scaling problem.

Q · I have one copy of the data and it works. What does a second copy actually buy me?

One node accepts all writes and everyone else copies it. This is the default arrangement in almost every database you will meet, and its real product is not the copies — it is a single agreed order of writes, obtained without any agreement protocol on the write path.

Q · Why do most replicated systems funnel every write through one node, when that node is obviously a bottleneck and a single point of failure?

The leader waits until a follower confirms the write before telling the client it succeeded. This is the only way to make an acknowledgement mean something across machines — and it makes the write path only as available as the followers it waits for.

Q · What does it take for "your write succeeded" to survive the immediate death of the node that said it?

The leader acknowledges the client and replicates afterwards. This is the default in most deployments, it is often the right choice, and its defining property is a window of acknowledged-but-unreplicated writes whose size you can measure and should know.

Q · If my replica is always a little behind, exactly how much data am I agreeing to lose, and when do I find out?

Two or more nodes accept writes for the same data and replicate to each other. It buys local write latency and write availability during a partition, and it buys them by making write conflicts a structural certainty rather than a rare accident.

Q · What actually changes when a second node is allowed to accept writes for the same key?

The weakest guarantee that keeps a user interface honest: whatever else a reader may miss, they must see the effects of their own writes. It is a per-session property, it is far cheaper than global consistency, and it is the fix for the most common replication bug in production.

Q · A user saves a change, the page reloads, and the change is gone. Nothing failed — so what guarantee was missing?

A reader who has seen a value must never subsequently see an older one. Without this, a page refresh can un-post a comment and a polling client can watch a counter oscillate — and unlike stale data, moving backwards is something users interpret as the system being broken.

Q · Why does hitting refresh sometimes show older data than the previous load, and why is that so much worse than merely being stale?

Write to W replicas, read from R, and if R + W > N the read set must intersect the write set. The arithmetic is trivially true. The conclusion people draw from it — "so I read the latest value" — holds only under assumptions that real systems routinely violate, and the assumptions are the lesson.

Q · If R + W > N guarantees my read set overlaps my write set, why can I still read a stale value?

No leader, no failover, no election. A coordinator writes to N replicas and waits for W, reads from R, and repairs what it finds out of date. It removes an entire class of operational problems and replaces them with a permanent, low-grade requirement to reconcile versions.

Q · What does a system look like when no node is special, and what does that cost?