Leader-Based Replication

Most production databases replicate data using a single leader (primary) that handles all writes. Changes flow from the leader to one or more followers (replicas) that serve read traffic. This is the default replication model in PostgreSQL, MySQL, MongoDB, and most managed database services (RDS, Cloud SQL, Atlas).

How It Works

flowchart LR
    C([Client]) -->|"all writes"| L[(Leader)]
    L -->|"replication stream"| F1[(Follower 1)]
    L -->|"replication stream"| F2[(Follower 2)]
    C2([Client]) -->|"reads"| F1
    C3([Client]) -->|"reads"| F2
    C4([Client]) -->|"reads"| L

Every write goes to the leader. The leader persists the change locally (WAL fsync), then streams it to followers via a replication log. Followers apply changes in order and serve read traffic. The leader can also serve reads, but in read-heavy systems, offloading reads to followers reduces primary load.

Setting Up New Followers

Adding a new follower to a running cluster cannot be done by simply copying the data directory — clients are writing continuously, so a naive copy would be inconsistent.

Handling Follower Failure

When a follower crashes and restarts, it knows the last transaction it applied (recorded in its local replication state). It reconnects to the leader and requests all changes from that point onward. The leader streams the missed transactions, and the follower catches up. No manual intervention needed — this is automatic in all modern databases.

Handling Leader Failure (Failover)

When the leader fails, a follower must be promoted to become the new leader. This process is called failover.

sequenceDiagram
    participant C as Client
    participant L as Leader (fails)
    participant F1 as Follower 1 (promoted)
    participant F2 as Follower 2

    C->>L: write W1, W2, W3
    L-->>F1: replicate W1, W2, W3
    L-->>F2: replicate W1, W2

    Note over L: Leader crashes

    Note over F1,F2: Failover: F1 has most recent data → promoted to leader

    C->>F1: writes now go to new leader
    F1-->>F2: F2 reconfigured to replicate from F1

Challenges in Failover

Replication Topologies

Single leader, direct replicas (standard):
    Leader → Follower 1
           → Follower 2
           → Follower 3

Chained (relay):
    Leader → Follower 1 (relay) → Follower 2 → Follower 3
    ↑ reduces leader fan-out, but adds cumulative lag

Multi-region:
    Leader (us-east) ─── async ───► Regional Follower (eu-west)
                    ─── async ───► Regional Follower (ap-south)

Why Not Multi-Leader?

In leader-based replication, only one node accepts writes. This avoids the write conflict problem entirely — there’s a single serialization point for all mutations. Multi-leader replication (where multiple nodes accept writes) introduces write conflicts that require resolution strategies (last-write-wins, CRDTs, application-level merge). The complexity is significant and only justified when write latency from a single region is unacceptable — covered in Multi-Region Design.

What This Means in Practice

Test Your Understanding