Database Replication: Copies for Speed and Survival (Primary-Replica Explained)
Database replication explained — how primary-replica setups copy data to scale reads and survive failure, sync vs async replication and replication lag, the read-your-writes trap, replication vs sharding, and multi-primary trade-offs.
🔵 Fundamentals · Fresher-friendly → 🟠 senior nuance
You've indexed your queries and cached what you can, but your single database is still getting hammered — and worse, if it dies, your whole app dies with it. The fix for both problems is the same: make copies of your database. This is replication, and it's how real systems get more read capacity and survive hardware failure. Let's build the idea from scratch, then hit the subtle consistency issues that make great interview material.
The setup: primary and replicas
The most common model is primary-replica (also called leader-follower or master-slave). One database is the primary: all writes (INSERT, UPDATE, DELETE) go there. Every change it makes is streamed to one or more replicas, which keep near-identical copies. Reads can be served by any of them.
Why it's such a big win
- Massive read scaling: most apps read far more than they write (thousands view a post for every one that writes it). Adding replicas multiplies your read capacity — 5 replicas ≈ 5× the reads — without touching the primary. This pairs perfectly with the read-heavy reality of the web.
- High availability: if the primary crashes, a replica can be promoted to become the new primary. Instead of an outage, you get a short blip. This is the backbone of database uptime.
- Backups & analytics: you can run heavy reports or nightly backups off a replica, so they never slow down the live primary.
The subtlety: sync vs async, and replication lag
🟠 How fast do changes reach the replicas? That's the crucial trade-off:
- Asynchronous (common): the primary confirms a write immediately and copies to replicas a moment later. Fast writes — but for a brief window, replicas are slightly behind. That gap is replication lag.
- Synchronous: the primary waits until a replica confirms before saying "done." No lag / stronger safety — but slower writes, and if the replica is slow, so is your write.
Most systems use async for speed and accept small lag. Which means a replica might briefly serve slightly old data — and that leads to a classic bug worth knowing.
The "read-your-writes" trap
🟠 Picture this: a user updates their profile name (write → primary). The page reloads and reads their profile (read → a replica that hasn't received the change yet). They see their old name and think the save failed. Confusing and real.
This is a consistency problem caused by replication lag. Common fixes: send that user's reads to the primary for a few seconds after they write, or read from the primary for data they just changed. Naming this trap — and its fix — in an interview is a strong senior signal. (The bigger topic of what "consistency" guarantees you can pick from is consistency models.)
Replication vs sharding — don't confuse them
A super common mix-up, so let's nail it:
| Replication | Sharding | |
|---|---|---|
| Does what | Full copies of the same data | Splits data into different slices |
| Solves | Read scaling + availability | Data too big / write scaling |
| Each node has | Everything | Only its portion |
They solve different problems and are often used together (each shard is itself replicated). Sharding gets its own deep-dive in database sharding.
What about multi-primary?
🔴 You can also run multiple primaries that all accept writes (multi-master), which helps write availability and multi-region setups. But it opens a hard problem: if two primaries edit the same row at once, whose change wins? Resolving these write conflicts is genuinely difficult, so single-primary is the default unless you truly need otherwise. Knowing multi-primary exists — and why it's avoided — rounds out a senior answer.
The mental model to carry
When an interviewer says your reads are overwhelming the database, the crisp answer is: "Add read replicas and route reads to them, keeping writes on the primary — accepting small replication lag, and reading from the primary for read-your-writes cases." That one sentence shows you understand the win and the trade-off. That's the whole game.
What to read next
- Database Sharding — splitting data when it's too big for one machine
- Consistency Models — strong vs eventual, explained
- The CAP Theorem — the law behind these trade-offs
- ← The complete System Design guide (hub)
Frequently Asked Questions
What is database replication and why is it used?
Replication keeps live copies of a database on multiple machines. In a primary-replica setup, one primary takes all writes and streams changes to replicas that serve reads. It scales read capacity, provides high availability (a replica can be promoted if the primary fails), and lets backups and analytics run off a replica.
What is replication lag?
With asynchronous replication the primary confirms a write immediately and copies it to replicas a moment later, so for a brief window the replicas are slightly behind. That gap is replication lag, and it can cause a replica to serve slightly stale data.
What is the difference between replication and sharding?
Replication makes full copies of the same data to scale reads and provide availability; every node has everything. Sharding splits the data into different slices to handle data too big for one machine and to scale writes; each node holds only its portion. They solve different problems and are often combined.
