← DDIA

Chapter 05 · Replication

Replication

You updated your profile, refreshed, and it was gone. Then it came back.

One database on three machines pretending to be one. Every trick to keep them in sync leaks.

Three acts: 1. lag 2. sync 3. topology

The lag

Same client, three replicas. One gets there late.

U you L leader F1 follower · fast F2 follower · slow name: "Idrees" stale read replica caught up

Three anomalies lag creates: read-your-writes your own write vanishes monotonic reads time appears to move backward consistent prefix you see effects before causes

Sync or async

Same write, plotted on time. Ack when?

sync async 0 time → sync commit async commit Δt lag durable · 2/2 ack in 1 hop leader crash → write lost

Takeaway

Eventual consistency: your replicas will agree, just not right now.

Who holds the pen?

01

Single-leader

One node accepts writes. Followers copy it. Reads scatter.

WRITE PATH all writes → one leader.
CONFLICT no cross-replica conflicts (leader orders everything).
FAILS WHEN leader dies → failover, possible data loss.
EXAMPLES Postgres primary, MySQL primary, most OLTP databases.
02

Multi-leader

Two writers, same key, at once. Conflict is now your problem.

WRITE PATH any leader accepts · async replicate to peers.
CONFLICT must resolve · LWW, CRDT, or app logic.
USE FOR multi-datacenter · offline clients · collab editing.
WATCH OUT hidden conflicts silently pick a winner.
03

Leaderless

Write to w of n. Read from r of n. Quorum decides truth.

WRITE PATH client writes to w of n replicas.
READ PATH client reads from r replicas · newest wins.
QUORUM w + r > n · guarantees overlap.
EXAMPLES Dynamo, Cassandra, Riak.

Three topologies · three answers to who accepts writes. Same client, same three replicas, different arrows.