Chapter 07 — Database Replication
Chapter 07 — Database Replication
Hey everyone! Welcome back to Namaste System Design! 🙏
Your app servers are horizontally scaled, you've added a cache — but everything still funnels into one database. That single DB is now your biggest weakness: if it's slow, everyone's slow; if it dies, everyone's down. The first fix is replication — keeping copies. Let's see how.
What we will cover:
- What replication is (the photocopy analogy)
- Leader-Follower (master-slave) replication
- How it scales reads and boosts availability
- Replication lag & the "read-your-own-write" problem
- Sync vs async replication
- Multi-leader & leaderless (a peek)
- Interview Questions
1. The Photocopy Analogy
Imagine one precious library book everyone wants to read. With one copy, there's a huge queue, and if it's lost, the knowledge is gone forever. So the library makes photocopies. 📚
┌─────────────────────────────────────────────────────────────┐ │ REPLICATION = keeping multiple copies of your database. │ │ │ │ Many copies → many people read at once (no queue) │ │ → one copy burns? others survive (safety) │ └─────────────────────────────────────────────────────────────┘
2. Leader-Follower Replication (The Classic)
The most common setup: one leader (handles all writes) and several followers (copies that handle reads).
WRITES
[ App ] ──────────────────▶ [ LEADER DB ] (the only writer)
│
replicates changes to ↓ ↓ ↓
┌──────────────────┬──────────────────┐
[ Follower 1 ] [ Follower 2 ] [ Follower 3 ]
▲ ▲ ▲
└─────── READS ────┴──────────────────┘
[ App ] reads from any follower
Writes → ONE leader. Reads → MANY followers.
(You'll also hear the older names master-slave, or primary-replica. Same idea.)
3. Why This Is Powerful
✅ READ SCALING → most apps are read-heavy (e.g. 100 reads
per 1 write). Add followers → handle more
reads without touching the leader.
✅ AVAILABILITY → leader dies? PROMOTE a follower to become
the new leader (this is "failover").
✅ GEO-LOCALITY → put a follower near your users (India, US,
EU) so reads are fast everywhere.
✅ BACKUPS/ANALYTICS → run heavy reports on a follower so the
main DB isn't slowed down.
4. The Catch: Replication Lag
Copying from leader to followers isn't instant. For a few milliseconds (sometimes seconds under load), a follower is behind the leader. This gap is replication lag, and it causes a famous bug:
THE "READ-YOUR-OWN-WRITE" PROBLEM
─────────────────────────────────
1. You post a comment → written to LEADER ✅
2. Page reloads, reads → from a FOLLOWER that hasn't
received the copy yet
3. Your own comment is MISSING! 😱 "Did it fail??"
...then a second later it appears. Confusing and bad UX.
Fixes:
✔ Read-your-writes: send a user's reads to the LEADER for a few seconds right after they write. ✔ Route critical reads (e.g. your own profile) to the leader. ✔ "Monotonic reads": keep a user pinned to one follower so they never see data go backwards.
5. Synchronous vs Asynchronous Replication
| Synchronous | Asynchronous | |
|---|---|---|
| How | Leader waits for followers to confirm before saying "done" | Leader replies "done" immediately, copies followers later |
| Data safety | Strong — no data lost if leader dies | Risk — recent writes can be lost if leader dies before copying |
| Speed | Slower writes (must wait) | Fast writes |
| Used by | Systems needing zero data loss | Most systems (speed wins) |
A common middle ground: semi-synchronous — the leader waits for one follower to confirm (safety) but not all of them (speed).
6. Beyond One Leader (A Quick Peek)
SINGLE-LEADER → one writer. Simple. (what we studied)
MULTI-LEADER → multiple writers (e.g. one per region).
Fast global writes, but CONFLICTS when two
leaders edit the same row. Needs conflict
resolution.
LEADERLESS → any node accepts writes (Cassandra, DynamoDB).
Uses "quorums" (R + W > N) for consistency.
Great availability, more complex.
For most interviews, single-leader is the default you describe; mention the others to show depth.
Interview Questions — Quick Fire!
Q: What is database replication and why do we use it?
"Replication keeps multiple copies of a database in sync across different machines. We use it for two main reasons: to scale reads, since most apps are read-heavy and we can spread reads across many replicas; and for high availability, because if one database fails, another copy can take over. It also enables geo-local reads and offloading analytics."
Q: Explain leader-follower replication.
"One node is the leader and handles all writes. It streams its changes to one or more followers, which are read-only copies. Reads are distributed across the followers to scale read capacity, while all writes go through the single leader to keep them consistent. If the leader dies, a follower is promoted to become the new leader."
Q: What is replication lag and what problem does it cause?
"Replication lag is the delay between a write landing on the leader and appearing on the followers. It causes the read-your-own-writes problem: a user writes data, then reads from a follower that hasn't caught up, so their own change seems to be missing. We fix it by routing a user's reads to the leader briefly after they write, or pinning them to one replica."
Q: What's the difference between synchronous and asynchronous replication?
"With synchronous replication, the leader waits for followers to confirm a write before acknowledging it — this guarantees no data loss but makes writes slower. With asynchronous replication, the leader acknowledges immediately and copies to followers afterward — writes are fast, but recent writes can be lost if the leader crashes before replicating. Most systems use async, sometimes semi-sync as a compromise."
Key Points to Remember
| Concept | Key Takeaway |
|---|---|
| Replication | Multiple synced copies of the DB → read scaling + availability. |
| Leader-Follower | Leader takes all writes; followers serve reads. Promote a follower on failover. |
| Replication lag | Followers trail the leader → read-your-own-writes bug. Route fresh reads to leader. |
| Sync vs async | Sync = safe but slow · Async = fast but can lose recent writes. |
| Limit | Replication scales READS, not writes or storage size — that needs sharding. |
What's Next?
Replication copies the whole database, so it scales reads but not writes or total size. When your data is simply too big for one machine, you must split it. Chapter 08 covers sharding & partitioning — the art of chopping one giant database into many.
Keep designing, keep scaling! See you in the next one!
Post a Comment