Read Replica — Database Scaling

A Read Replica is a copy of the primary database that is mainly used to handle read traffic.

It is one of the most common techniques for scaling a database when the application has significantly more reads than writes.

The Problem

Imagine an application receiving:

100,000 requests/second

90,000 Reads
10,000 Writes

If every request goes to one database, the database can become a bottleneck.

flowchart LR
    U[Users] --> API[Application]

    API --> DB[(Primary Database)]

    DB --> R[Reads + Writes]

    Note[Single Database Bottleneck]

Read Replica Architecture

We can keep writes on the primary and distribute reads across replicas.

flowchart LR
    U[Users] --> API[Application]

    API -->|Writes| P[(Primary Database)]

    API -->|Reads| R1[(Read Replica 1)]
    API -->|Reads| R2[(Read Replica 2)]
    API -->|Reads| R3[(Read Replica 3)]

    P -->|Replication| R1
    P -->|Replication| R2
    P -->|Replication| R3

Complete Example — E-Commerce

Suppose an e-commerce application has:

100,000 requests/second

95,000 Read requests
5,000 Write requests

Typical reads:

• Product details
• Product catalog
• Order history
• Search results
• Customer profile

Typical writes:

• Create order
• Update inventory
• Payment status
• Update customer information

flowchart TD
    API[Application]

    API -->|Create Order| P[(Primary)]
    API -->|Update Inventory| P
    API -->|Payment Update| P

    API -->|Product Read| R1[(Read Replica 1)]
    API -->|Order History| R2[(Read Replica 2)]
    API -->|Catalog Read| R3[(Read Replica 3)]

    P --> R1
    P --> R2
    P --> R3

How It Works

sequenceDiagram
    participant Client
    participant API
    participant Primary
    participant Replica

    Client->>API: Create Order
    API->>Primary: INSERT Order
    Primary-->>API: Success
    API-->>Client: Order Created

    Primary->>Replica: Replicate Order

    Client->>API: Get Order
    API->>Replica: SELECT Order
    Replica-->>API: Order
    API-->>Client: Order Details

Important Problem — Replication Lag

A read replica may not immediately contain the latest data.

sequenceDiagram
    participant Client
    participant API
    participant P as Primary
    participant R as Replica

    Client->>API: Create Order
    API->>P: INSERT Order
    P-->>API: Success
    API-->>Client: Order Created

    Client->>API: Get Order
    API->>R: SELECT Order
    R-->>API: Order Not Found

    Note over R: Replica has not caught up yet

    P->>R: Replicate Order

This is called a read-after-write consistency problem.

How Do We Handle Read-After-Write?

Option 1 — Read From Primary

After a write, route related reads to the primary for a short period or for the current request/session.

flowchart LR
    W[Write] --> P[(Primary)]
    P --> R[Immediate Read]

    R --> P

Option 2 — Use Replica for Eventual Consistency

For data where a small delay is acceptable, continue reading from replicas.

For example, a product catalog may tolerate a short delay, while payment status may require stronger consistency.

Option 3 — Route Based on Operation

flowchart TD
    A[Read Request] --> B{Consistency Required?}

    B -->|Strong| P[(Primary)]
    B -->|Eventual OK| R[(Read Replica)]

Adding More Read Replicas

If read traffic continues increasing, additional replicas can be added.

flowchart LR
    API[Application]

    API --> R1[(Replica 1)]
    API --> R2[(Replica 2)]
    API --> R3[(Replica 3)]
    API --> R4[(Replica 4)]
    API --> R5[(Replica 5)]

    P[(Primary)] --> R1
    P --> R2
    P --> R3
    P --> R4
    P --> R5

This can significantly increase read capacity, assuming the primary and replication mechanism can support the additional replication workload.

Read Replica Does Not Solve Everything

Suppose we have:

10 Read Replicas
1 Primary

Read traffic = 1 million requests/sec
Write traffic = 500,000 requests/sec

If the primary is the write bottleneck, adding more read replicas will not solve the write-scaling problem.

flowchart LR
    W[Heavy Write Traffic] --> P[(Primary)]

    P --> R1[(Replica)]
    P --> R2[(Replica)]
    P --> R3[(Replica)]

    Note over P: Write Bottleneck remains

At that point, other techniques such as partitioning, sharding, batching, caching, or workload-specific database architecture may need to be considered.

Read Replica vs Cache

Production Architecture

flowchart TD
    U[Users] --> LB[Load Balancer]
    LB --> API[API Servers]

    API --> C[(Redis Cache)]

    API -->|Write| P[(Primary Database)]

    API -->|Read| R1[(Read Replica 1)]
    API -->|Read| R2[(Read Replica 2)]
    API -->|Read| R3[(Read Replica 3)]

    P -->|Replication| R1
    P -->|Replication| R2
    P -->|Replication| R3

    P --> B[Backup / Recovery]

Interview Scenario

Interviewer: Your database has very high read traffic and relatively low write traffic. How would you scale it?

Answer:

1. Analyze queries and optimize indexes first.
2. Introduce caching for frequently accessed data.
3. Add read replicas for read-heavy workloads.
4. Route suitable read traffic to replicas.
5. Keep writes on the primary.
6. Monitor replication lag.
7. Handle read-after-write consistency explicitly.
8. Add more replicas as read demand grows.
9. If writes become the bottleneck, evaluate partitioning or sharding rather than simply adding read replicas.

Common Interview Questions

• What is a read replica?
• Why do we need read replicas?
• Can a read replica handle writes?
• What is replication lag?
• How do you solve read-after-write consistency?
• Read replica vs cache?
• Can read replicas scale database writes?
• What happens if the primary database fails?
• How would you scale millions of read requests?

Key Takeaways

• Primary → handles writes.
• Read replicas → handle suitable read traffic.
• Read replicas improve read scalability and can support availability architectures.
• Replication lag can cause stale reads.
• Read-after-write consistency must be handled deliberately.
• Read replicas do not solve a primary write bottleneck.
• Caching and read replicas solve different problems and are often used together.

Conclusion

A read replica is one of the simplest ways to scale a read-heavy database workload. The key interview concept is:

Writes → Primary | Reads → Replicas | Replication Lag → Consistency consideration