Read replicas in HLD - System Design Guide

Problem Statement

When a database receives too many read requests, a single server can become overwhelmed, causing slow responses and potential downtime. This bottleneck limits the system's ability to serve users quickly and reliably, especially during traffic spikes.

Solution

Read replicas solve this by creating copies of the primary database that handle read requests. The primary database processes all writes and updates, then asynchronously replicates data to the read replicas. This spreads the read load across multiple servers, improving performance and availability.

Architecture

Primary DB

(Writes)

→Read Replica 1

↓

→Read Replica 2

This diagram shows a primary database handling all write operations and asynchronously replicating data to multiple read replicas that serve read requests.

Trade-offs

✓ Pros

→

Distributes read traffic to multiple servers, reducing load on the primary database.

→

Improves read query performance and reduces latency for users.

→

Increases system availability by allowing reads to continue if the primary is busy or down.

✗ Cons

→

Data replication is asynchronous, so read replicas may serve slightly stale data.

→

Adds complexity in managing replication lag and consistency.

→

Write operations still depend on the primary database, which can remain a bottleneck.

Use read replicas when read traffic exceeds 1,000 requests per second or when read latency impacts user experience significantly.

Avoid read replicas if your application requires strict read-after-write consistency or if read traffic is low (under 1,000 req/sec), where replication overhead outweighs benefits.

Real World Examples

Amazon

Amazon uses read replicas in their DynamoDB and RDS services to handle massive read workloads while keeping write operations consistent on the primary.

Netflix

Netflix employs read replicas to serve user data and streaming metadata quickly, reducing load on the primary database during peak hours.

Airbnb

Airbnb uses read replicas to scale their search and listing read queries, ensuring fast response times without affecting write performance.

Alternatives

Caching

Caching stores frequently accessed data in fast storage like memory, reducing database reads, while read replicas duplicate the entire database for reads.

Use when: Choose caching when data can be stale for short periods and you want ultra-fast access to specific queries.

Sharding

Sharding splits the database horizontally into smaller parts, each handling a subset of data, unlike read replicas which copy the full dataset.

Use when: Choose sharding when your dataset is too large for a single database and you need to scale writes and reads horizontally.

Summary

Read replicas improve system performance by distributing read traffic across multiple database copies.

They help reduce latency and increase availability but may serve slightly stale data due to asynchronous replication.

Use read replicas when read demand is high and strict immediate consistency is not required.