Leader-Follower Replication

Single-leader replication: how followers catch up, failover, and read-after-write issues.

One leader handles ALL writes. Followers copy from leader and handle reads.

2. Replication log

Leader writes to a special log (WAL in PostgreSQL, binlog in MySQL). Followers pull from this log and apply changes in the same order.

ADDING NEW FOLLOWERS

You cannot just copy the data — the leader keeps getting new writes during the copy. Step 1 — Take a snapshot of leader's data at a specific point in time. Step 2 — Copy that snapshot to the new follower. Step 3 — Follower connects and says: give me all changes since the snapshot. Step 4 — Follower catches up and is now in sync. Done.

Leader Failure

Follower fails: → It reconnects and asks: give me log from position X where I left off. → Catches up. Easy. Leader fails (FAILOVER): Step 1 — Detect leader is dead (wait for timeout, not just slow) Step 2 — Pick the most up-to-date follower as new leader Step 3 — Redirect all client writes to new leader Step 4 — Old leader comes back → now becomes a follower

Used by: PostgreSQL, MySQL, MongoDB, Redis — the most common setup in production.

TYPE-1 : LEADER-FOLLOWER — HOW IT WORKS

WAL - Write Ahead Logging