Database Replication — Making Copies of Your Exam Notes

What is Database Replication?

Before exams, you write detailed notes. But what if you lose your notebook? Smart students make photocopies and give them to friends. If the original is lost, the copies still exist.

Database Replication = keeping copies of your database on multiple servers so that if one fails, others can take over.

Why Replicate?

High Availability

If your primary database crashes at 2 AM, the replica takes over instantly. Users never notice.

Read Performance

Your app has 90% reads and 10% writes (typical for most apps). Instead of one database handling everything, spread reads across replicas.

Writes → Primary Database
Reads  → Replica 1, Replica 2, Replica 3

Disaster Recovery

Primary database is in Mumbai. Replica is in Singapore. If the Mumbai data center floods, Singapore has all your data.

Master-Slave (Primary-Replica) Replication

The most common pattern:

        ┌──────────┐
        │  Primary  │ ← All WRITES go here
        │ (Master)  │
        └────┬─────┘
             │ replicates data
     ┌───────┼───────┐
     ▼       ▼       ▼
┌────────┐┌────────┐┌────────┐
│Replica 1││Replica 2││Replica 3│ ← READS distributed here
└────────┘└────────┘└────────┘

How it works:

1. App writes data to the Primary

2. Primary logs the change

3. Replicas pull the log and apply the same change

4. All replicas eventually have the same data

Real example: Instagram. When you post a photo, it's written to the primary database. Your followers read your post from replicas closest to them.

Synchronous vs Asynchronous Replication

Synchronous

Primary waits until ALL replicas confirm they've received the data before telling the app "write successful."

Pros: Data is always consistent across all replicas

Cons: Slow writes (waiting for all replicas)

Analogy: You send a WhatsApp message and wait for blue ticks from EVERYONE before sending the next message.

Asynchronous

Primary writes data and immediately tells the app "success." Replicas catch up in the background.

Pros: Fast writes

Cons: Replicas might be slightly behind (replication lag)

Analogy: You send a WhatsApp message and move on. Blue ticks come later.

Most production systems use asynchronous replication because the speed trade-off is worth it. A few milliseconds of lag is acceptable for most use cases.

Replication Lag — The Tricky Part

With async replication, there's a small window where the primary has new data but replicas don't yet.

Scenario: User updates their profile name. The write goes to primary. User immediately refreshes the page, which reads from a replica. The replica hasn't caught up yet — user sees the OLD name.

Solutions:

• Read-your-own-writes: After a write, route that user's reads to the primary for a few seconds

• Monotonic reads: Ensure a user always reads from the same replica

• Consistent prefix reads: Ensure causally related writes are read in order

Multi-Master Replication

Multiple servers can accept writes. Used when you need writes in multiple regions.

┌──────────┐     ┌──────────┐
│ Master 1  │ ←→ │ Master 2  │
│ (Mumbai)  │     │ (Singapore)│
└──────────┘     └──────────┘

Pros: Low latency writes from any region

Cons: Write conflicts (what if both masters update the same row simultaneously?)

Used by: Google Docs (multiple people editing the same document), CockroachDB, DynamoDB Global Tables.

Key Takeaway

Replication = "Don't keep all your eggs in one basket." Keep copies of your data on multiple servers for availability, performance, and disaster recovery. In interviews, always discuss the trade-off between consistency and performance when choosing sync vs async replication.