Lesson 06

Replication

One copy of your database is a single point of failure. Replicate it and you gain durability and read scaling — but you inherit a new problem: which copies have the latest write?

The idea

A primary (or "leader") accepts writes. Each write is shipped to one or more replicas (or "followers") which apply it locally. Reads can be served by any replica — that's how databases scale read traffic.

The tradeoff hinges on when the primary tells the client "your write succeeded":

Async: as soon as the primary writes locally. Fast, but if the primary crashes before the write ships, the write is lost.
Sync: only after at least one replica has acked. Safer, but every write pays the round-trip cost.

Try it

Key takeaways

Replication trades latency for durability and read scale. Sync is safer; async is faster.
If a replica is down or slow in sync mode, writes stall everywhere. Operators tune timeouts carefully.
Replication lag means a read from a replica might see stale data. "Read your writes" needs special handling.
If the primary fails, a replica must be promoted — but only one that's caught up, or you lose data.