Database replication: leader-follower, lag and failover

Replication keeps copies of the same data on several servers. The goals are more read capacity, fault tolerance and sometimes lower latency by placing a copy near users.

Leader-follower (primary-replica)

One leader accepts all writes. Followers copy the changes and serve reads. Your app sends writes to the leader and spreads reads across followers. This is the most common setup (PostgreSQL, MySQL and many others).

Synchronous vs asynchronous

• Synchronous: the leader waits until a follower confirms. No data loss if the leader dies, but writes are slower and one slow follower can block them.
• Asynchronous: the leader answers right away and followers catch up. Fast, but recent writes can be lost in a crash.
• Many systems use one sync follower and the rest async.

Replication lag

Followers are slightly behind. A user saves a profile, refreshes, and reads from a lagging follower: their change seems to vanish. Ways to handle it:

• Read-your-writes: read from the leader for a short time after the user writes.
• Route sensitive reads to the leader.
• Accept staleness where it does not matter (like counts).

Failover

If the leader dies, a follower must be promoted. This can be automatic or manual. Risks: losing the last writes, and split brain, where two servers both think they are leader. Use a proper coordination tool and a fencing mechanism.

Other models

Multi-leader (several accept writes, conflicts must be resolved) and leaderless (Dynamo-style quorum reads and writes) exist for special needs.

Takeaway: use leader-follower for read scaling and safety, design for lag, and rehearse failover before you need it.

---

Part 9 of 15 in the System Design series. Previous: Database sharding: splitting data across servers.