Concept · Replication & partitioning
Leader–follower replication
One node takes writes and streams them to read replicas; sync, async and failover.
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.
- 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).
- Writes don't scale: every write still goes to one node; for that you need partitioning.
The log being shipped is the write-ahead log.