Leader-Follower Replication

Table of Contents

🔴 P0 — the default replication strategy for most production databases

Problem #

A single database instance is a single point of failure and a read throughput bottleneck. You need copies of the data for fault tolerance and read scaling.

Mechanism #

Writes → [Leader] ──(replication log)──→ [Follower₁] ← Reads
                  ──(replication log)──→ [Follower₂] ← Reads
                  ──(replication log)──→ [Follower₃] ← Reads

All writes go to the leader
Leader streams changes (via WAL or logical replication) to followers
Reads can go to any replica (with caveats)

Key Trade-offs #

Replication Lag #

Synchronous replication: Follower confirmed write before leader acks. Strong consistency, but leader blocked if follower is slow.
Asynchronous replication: Leader acks immediately. Fast, but followers may serve stale data.
Semi-synchronous: One follower is synchronous (guarantees at least one up-to-date copy), rest async.

Read-After-Write Consistency #

If a user writes via the leader and immediately reads from a follower, they might not see their own write. Solutions: read-your-writes from leader, causal consistency tokens, or synchronous replication to at least one follower.

Geographic Replication #

Single leader, multi-region followers: Writes go to one region, reads served locally
Multi-leader: Each region has a leader. Writes fast everywhere, but conflict resolution is the challenge

Instinct: For read-heavy workloads (>90% reads), single-leader with regional read replicas is simpler and sufficient. Consider multi-leader or distributed SQL for write-heavy global workloads.

Instinct #

Default to async replication with read-your-writes guarantee on critical paths. Most reads can tolerate milliseconds of lag. For the critical paths (user just submitted a form, redirect to confirmation page), route reads to the leader or use a consistency token.

References #

DDIA 2e Reference #

Chapter 5: Leaders and Followers — this IS Chapter 5’s opening content