Replication

What it is

Replication keeps more than one copy of the data. It buys durability (data that outlives any one disk), read capacity, and the ability to survive a machine dying. The cost is that copies can disagree, and every replication design is an answer to when they are allowed to.

Leader-follower

One node accepts writes and streams its change log to the others, which apply it in order. Reads can go anywhere. This is the common shape: Postgres, MySQL, Redis, and most managed databases.

The one decision that matters is whether the leader waits.

Synchronous. The leader does not acknowledge a write until followers have it. A failover (a follower taking over as leader) loses nothing, because everything acknowledged is everywhere. Every write pays a round trip to the slowest follower, and if a follower is down, writes stop — which is why almost nobody runs fully synchronous replication.

Asynchronous. The leader acknowledges immediately and ships changes in the background. Writes are fast and stay up when a follower is sick. In exchange, anything still in flight when the leader dies is gone — and it had already been acknowledged to the client. The widget makes this the punchline: write a few times, kill the leader mid-flight, and read the number of writes that no longer exist.

Semi-synchronous is the usual compromise: wait for one follower. Bounded loss, one machine's worth of availability risk.

Replication lag

Followers are behind by an amount that varies with load. This produces a family of bugs that look like the database lying:

• A user writes, is redirected, reads from a follower, and their own change is missing (read-your-writes).
• A user refreshes and sees older data than a moment ago, because they landed on a different follower (monotonic reads).

Both are routing problems, not storage problems. Send a user's reads to the leader for a few seconds after they write, or pin a session to one replica.

Failover

Detect that the leader is dead, elect a successor, redirect writes. Every step has a failure mode. Detection is a guess — a slow leader and a dead one look identical from outside — and getting it wrong produces split brain, two nodes both accepting writes, which is the worst outcome available. Fencing tokens (a number that rises with every new leader, so writes from an old one are refused) and quorum-based election exist to make that impossible rather than unlikely.

Multi-leader and leaderless

Multi-leader puts a writable node in each region: low local write latency, and now write conflicts are a routine occurrence rather than an emergency.

Leaderless (Dynamo-style) sends every write to N nodes and waits for W. There is no failover because there was no leader. Consistency becomes a per-request dial via R and W rather than a fixed property of the system.

Take this with you

• The one idea: copies can disagree. Every replication setup is a decision about when that is allowed and what a reader is promised.
• In an interview, say leader-follower, async by default, and name the two lag bugs (read-your-writes, monotonic reads) and how routing fixes them.
• At work, find out how far behind your replicas run at peak, and whether anything reads its own write from a follower.