Core idea
Replication = keeping a copy of your data on multiple nodes. Solves two problems: availability (one node dies, others serve) and read scalability (spread read load across replicas).
Mental model
Think of it as a master document and photocopies. The original (leader) receives all edits. Photocopies (followers) are always slightly behind. For reading information, any copy works. For making changes, you must go to the original.
Why it matters
- Single database node is a single point of failure
- Read-heavy systems can serve 10x traffic by adding read replicas
- Understanding replication lag helps you reason about consistency
What to know
- Leader-follower (master-slave): all writes to leader, reads from followers — most common
- Multi-leader: writes to any leader, sync between leaders — good for multi-region, but conflict resolution is hard
- Leaderless (Dynamo-style): write to multiple nodes, quorum (W+R>N) determines consistency
- Replication lag: followers are always slightly behind — reads may be stale
- Synchronous vs async replication: sync = no data loss, slower | async = fast, can lose last writes on crash
Common traps
- Reading your own write from a replica that hasn’t synced yet — UX disaster
- Multi-leader conflicts are hard: two users updating same record simultaneously
- Assuming replicas are free — they have write overhead, network cost
Recognise it
Recognition trigger: High read QPS → add read replicas. Need zero data loss on failover → at least one synchronous replica (it buys durability, and can block writes if that replica is down). Need high availability → replicas plus automatic failover. Multi-region → consider multi-leader but plan conflict resolution strategy.
Practice question
A user updates their bio. Immediately they check their profile and see the old bio. Why? How do you fix it?
Apply at work
Answer these for the system you work on.
Go deeper
- Chapter 5: Replication · Designing Data-Intensive Applications (Kleppmann), book