How does leader-follower database replication work?
All writes go to one leader, which streams its changes to follower replicas. Followers serve reads, which spreads read load and gives a standby copy if the leader fails, but they may lag behind.
Explain it simply
Think of a class monitor who writes the official notice on the board (the leader) while students copy it into their own notebooks (followers). Anyone can read a notebook, but only the monitor changes the original.
How it works:
- A client writes to the leader.
- The leader records the change in a log (the write-ahead or binlog).
- Followers read that log and apply the same changes in order.
- Read-only queries are spread across followers.
Benefits: higher read throughput, a hot standby for failover, and copies for backups and analytics without slowing production.
Costs:
- Replication lag: a follower can be behind, so a user may not see their own just-made change if the next read hits a lagging follower.
- Writes do not scale, because one leader takes all of them.
- Failover needs care: promote the most up-to-date follower and make sure the old leader does not also keep accepting writes.
Replication can be synchronous (leader waits for followers, safer, slower) or asynchronous (faster, can lose recent writes on a crash).
Example
A user posts a comment, then refreshes.
Write -> leader (comment saved)
Refresh -> follower 2 (still 200 ms behind) -> comment missing!
Fix: read your own recent writes from the leader,
or route that user to the leader for a few seconds.What to say in the interview
"Writes go to a single leader, which ships its log to followers that serve reads and act as standbys. It scales reads, not writes, and asynchronous replication means lag and possible data loss on failover. I handle read-your-writes by reading from the leader after a write."