Replication

Replication keeps copies of the same data on multiple database nodes. You do it for two reasons: to survive a machine dying, and to serve more reads. The standard setup is leader-follower — all writes go to one leader, and followers copy from it and serve read traffic.

In the animation, green write dots hit the leader cylinder and stream copies out to two followers — with a visible delay bar of about one second. That delay is replication lag: with asynchronous replication, the leader confirms your write before the followers have it. Watch a read hit a follower and come back slightly faded — a stale read. A minute-old feed is fine; a minute-old bank balance is not. The user-facing version of this problem is read-your-own-writes: you post a comment, refresh, and it is gone because your read hit a lagging follower.

Then the leader explodes. A follower animates a crown promotion — failover — and writes resume against the new leader. Any writes the dead leader had not yet replicated are the risk you accepted by going asynchronous.

In interviews, "add read replicas" is the expected first answer to read scaling — before anything exotic — and "what if the leader dies?" is the standard probe. Be ready to state the stale-read consequence in one sentence.