Replication

Replication means keeping more than one copy of your data on different servers. Teams reach for it for two reasons. The first is fault tolerance: if the only copy of your data lives on one machine and that machine dies, you have an outage and possibly data loss. With replicas, another copy can take over. The second is read scaling: most systems read far more than they write, and a single database can become a read bottleneck. Spreading reads across several copies multiplies your read capacity.

It is worth being precise about the difference from sharding, because they are often confused. Replication copies the same data to many servers. Sharding splits different data across servers. Replication scales reads and survives failures; sharding scales writes and storage. Large systems usually do both: shard the data into pieces, then replicate each piece.

The most common arrangement is leader-follower, also called primary-replica or master-slave. One server is the primary and is the only one that accepts writes. It records every change to its data and streams that change log to the followers, the replicas, which apply the same changes in the same order. Reads can be served by the primary or, more usefully, spread across the replicas to take load off the primary.

If the primary fails, one of the replicas is promoted to be the new primary, a process called failover. This is why even a system that does not need extra read capacity often keeps at least one replica: it is the difference between a quick failover and a long outage with a restore from backup.

The key choice is when the primary considers a write done. With synchronous replication, the primary waits for at least one replica to confirm it has the change before telling the client the write succeeded. This guarantees the replica is current, but the write is only as fast as the slowest replica it waits for, and if that replica is down the write stalls.

With asynchronous replication, the primary acknowledges the write immediately and streams it to replicas in the background. This is fast and the primary never waits, but it opens a gap: for a brief moment the replicas are behind the primary. That gap is replication lag, often a few milliseconds but sometimes seconds under load.

Replication lag causes a specific, surprising bug. A user writes something, the write goes to the primary, then their next read is served by a replica that has not caught up yet, so their own change appears to have vanished. This is the read-your-own-writes problem. Common fixes are to route a user's reads to the primary for a short window after they write, or to use replicas that track how far behind they are and skip the ones that are too stale.

Leader-follower has one writable node, which is simple but means all writes funnel through one machine and one region. Two other models trade simplicity for write availability. Multi-leader replication allows writes on more than one primary, which helps across regions, but creates write conflicts when two leaders change the same row, so it needs conflict-resolution rules.

Leaderless replication, used by systems like Cassandra and the original Dynamo, drops the special primary entirely: a client writes to several nodes at once and reads from several at once, using quorums to decide what the current value is. It is highly available and partition tolerant, at the cost of weaker consistency guarantees that the application has to reason about.