NOTE
4.3 Single-Leader Replication
How leader/follower replication handles writes, reads, initial synchronization, incremental catch-up, leader election, and failover.
This is a historical learning note and may contain outdated or incomplete understanding.
1. What Is Single-Leader Replication?
One replica is the leader for writes; other replicas are followers that copy the leader’s log or state changes. Followers may serve reads when the required consistency model allows it.
2. Leader Selection
Leadership can be assigned manually, coordinated by an external service, or elected by a protocol such as Raft.
A safe election must account for both liveness and log freshness. Simply choosing the numerically smallest/largest node ID is not sufficient for a replicated log with committed data.
Network partitions create a split-brain risk if independent sides both accept incompatible leadership. Quorum-based protocols prevent two disjoint minorities from independently committing authoritative histories.
3. Data Synchronization
3.1 Initial Synchronization
A new follower often receives a snapshot or base copy and then replays changes generated after that snapshot.
3.2 Incremental Catch-Up
A returning follower can resume from its known replication position if the leader still retains the required log. Otherwise it may need another full snapshot.
See Replication Strategies and Replication Logs.
4. Request Handling
Writes go to the leader. Reads may go to the leader or followers; follower reads can be stale when replication is asynchronous.
5. Failure Recovery
Follower failure normally reduces redundancy. Leader failure requires choosing a replacement, redirecting writers, and ensuring the new leader’s history is safe before accepting new writes.