Leader-Based Replication

Leader-based replication

One leader (primary) accepts all writes and streams changes to followers (replicas). Clients may read from followers to scale reads — at the cost of staleness.

Client write → Leader → replicate log → Followers apply Client read → Follower (possibly stale) OR Leader (fresh)

Sync vs async replication

Mode	Durability	Latency	Failover risk
Sync	Write ack only after follower(s) persist	Higher	Lower data loss
Async	Leader acks after local write	Lower	Lost writes if leader dies before replicate

Semi-sync — wait for one follower, async to the rest — common compromise.

Replication lag

Followers fall behind under load. Symptoms:

• User posts content, refresh shows old feed (read from stale replica)
• Unique constraint appears to "flicker" across replicas
• Read-your-writes violated unless you route reads to leader or track position

Fixes: sticky sessions, monotonic reads via version tokens, or read from leader for critical paths.

Failover

When leader dies, promote a follower. Hard parts:

• Split brain — two nodes think they're leader
• Lost writes — async lag at crash time
• Fencing — stale leader must be prevented from accepting writes (Topic 6)

Tools: etcd, ZooKeeper, Raft-based systems elect the new leader with consensus.

Not covered here

Single-node Postgres transaction isolation — see Databases roadmap. This topic is multi-copy semantics only.