Database Replication

Why It Matters

A single database becomes a bottleneck quickly.

Example:

• Primary DB capacity: 3,000 queries per second
• Traffic: 12,000 read queries per second

Result:

• high latency
• request failures

Replication helps distribute load and improve reliability.

What This Concept Actually Means

Replication means copying data from one database to one or more replicas.

• Primary handles writes
• Replicas handle reads

Think like this:

• Primary = source of truth
• Replicas = read copies

How It Works

Let’s take a social media feed system.

Setup

• 1 primary database
• 3 read replicas

Traffic

• Writes: 2,000 per second
• Reads: 10,000 per second

Flow

• All writes go to primary
• Reads distributed across replicas

Result

• Each replica handles around 3,300 reads per second
• Primary focuses on writes

Replication lag example:

• Write happens at time 0
• Replica updated after 1 to 2 seconds
• Users may see slightly stale data

Flow:

Diagram
flowchart LR
  App --> PrimaryDB
  PrimaryDB --> Replica1
  PrimaryDB --> Replica2
  PrimaryDB --> Replica3
  App --> Replica1
  App --> Replica2
  App --> Replica3
visualized by

Key Techniques / Variations

1. Master Slave Replication

• One primary
• Multiple replicas

Use case:

• read-heavy systems

2. Multi Master Replication

• Multiple nodes accept writes

Use case:

• global systems

Trade-off:

• conflict resolution complexity

3. Synchronous Replication

• Write completes only after replicas confirm

Benefit:

• strong consistency

Trade-off:

• higher latency

4. Asynchronous Replication

• Primary responds before replicas update

Benefit:

• low latency

Trade-off:

• eventual consistency

Trade-offs and Design Decisions

When to use replication

• read-heavy workloads
• need high availability

Pros

• improves read scalability
• increases availability
• enables failover

Cons

• replication lag
• data inconsistency issues
• added infrastructure cost

Real-world example

• Primary handles 3,000 queries per second
• Add 3 replicas
• Total read capacity becomes around 12,000 queries per second

Cost example:

• 1 DB server: 20k per month
• 4 DB servers: 80k per month

But system can handle 4x traffic and avoid downtime

Architecture / Flow Diagram

Diagram
flowchart LR
  Client --> API
  API --> PrimaryDB
  PrimaryDB --> Replica1
  PrimaryDB --> Replica2
  API --> Replica1
  API --> Replica2
visualized by

Failure Modes To Watch

• replication lag causing stale reads
• replica falling behind
• failover delays
• split brain in multi master systems

Design Checklist

Ask yourself:

• What is read vs write ratio?
• Is stale data acceptable?
• What is acceptable replication lag? (e.g., 1 to 2 seconds)
• Do I need failover strategy?
• Should I use sync or async replication?

Summary

• Replication copies data across multiple databases
• It improves scalability and availability
• Primary handles writes, replicas handle reads
• Async replication is common but introduces lag
• Always plan for failover and consistency trade-offs