# Leader–follower replication

> One node takes writes and streams them to read replicas; sync, async and failover.

Concept · Replication & partitioning · https://levelcode.org/concepts/leader-follower-replication

In leader–follower replication (also primary–replica), one node — the **leader** — accepts all writes. It records them in its log and streams the log to **followers**, which apply the changes in the same order and serve reads. PostgreSQL, MySQL, MongoDB, Redis and most managed databases work this way.

## Why it's the default

Every change passes through one node in one order, so followers never disagree about order — they can only be **behind**. That makes the system easy to reason about compared with designs that accept writes in several places.

## Synchronous or asynchronous

| Mode | Commit acknowledged after | Trade-off |
|---|---|---|
| Asynchronous | The leader's own log is durable | Fastest; writes not yet shipped are lost if the leader dies |
| Synchronous | At least one follower also has it | No acknowledged write is lost; each commit waits a round trip |
| Semi-synchronous | One follower has received it | Most of the safety, slightly less latency |

Waiting for **one** follower (or any one of several) rather than all of them keeps writes available when a single replica is down.

## Uses

- **Read scaling:** spread read queries over followers.
- **Availability:** promote a follower if the leader fails.
- **Durability and backups:** take backups from a follower without loading the leader.
- **Geography:** put a follower near distant users for local reads.

## The catches

- **Lag:** asynchronous followers can be milliseconds to minutes behind, which causes [replication lag anomalies](https://levelcode.org/concepts/replication-lag).
- **Failover is hard:** detecting a dead leader, choosing the most up-to-date follower, redirecting clients, and making sure the old leader can't keep accepting writes (split brain). Use a tool built for it — Patroni, a managed service — which relies on consensus to agree on the leader ([leader election](https://levelcode.org/concepts/leader-election)).
- **Writes don't scale:** every write still goes to one node; for that you need [partitioning](https://levelcode.org/concepts/sharding).

The log being shipped is the [write-ahead log](https://levelcode.org/concepts/write-ahead-log).