Replication for Availability

Sharding solves a throughput ceiling; replication solves a different problem — a single copy of the data is also a single point of failure, and a single machine can only serve so many concurrent readers. Replication keeps one or more additional copies of a shard's data on separate machines, so a failed primary can be replaced and read traffic can be spread across replicas. The common shape is leader-follower (or primary-standby): one node accepts writes, and every other node applies the same stream of changes after the fact, so they converge on the same state without ever being written to directly.

How closely a follower tracks the leader is a choice, not a fixed property. PostgreSQL's documentation on streaming replication describes the default mode plainly: the primary streams its write-ahead log (WAL) to a standby as changes are generated, and by default this is asynchronous — the primary commits and returns to the client without waiting for the standby to confirm it received anything. Synchronous replication flips that: the primary's commit waits until at least one standby confirms it has the change, which closes the data-loss window at the cost of added commit latency, since every write now pays for a round trip to the standby before it can complete.

Failover is where the trade-off shows up concretely. If a primary using asynchronous replication crashes, any transaction it committed but hadn't yet streamed to a standby is gone the moment a standby is promoted to take its place — the standby simply didn't have it. The gap between what the primary committed and what a standby has applied is replication lag, and it grows under load or network trouble; a design that reads from replicas has to decide whether a slightly stale read is acceptable, or whether that particular read has to go to the primary. A synchronous replica removes the data-loss risk on failover, but only for the standby actually named as synchronous — the rest of the fleet, if any, stays asynchronous.