Horizontal Scaling in Databases: Part 1 — Read Replicas

As applications grow, databases are often the first thing to feel the pressure because systems ask a lot from them. Thousands of users reading data, refreshing pages, loading feeds all at the same time.

One important observation drives the design shown in this diagram:

Most applications have the read to write ratio very huge.

The Core Problem: One Database, Too Much Load

If a single database handles everything from reads and writes, it eventually becomes a bottleneck. Even if writes are limited, heavy read traffic can slow down the system, increase latency, and affect write performance.

At scale, the goal is not just to store data correctly, but to serve it efficiently.

Replication is the strategy that allows this.

Separating Responsibilities

A replicated database system typically assigns different responsibilities to different nodes.

One database acts as the primary source of truth. It is responsible for accepting all write operations. Any change to data inserts, updates, deletes happens here first.

Other databases act as replicas. Their job is not to modify data, but to serve read requests. They maintain copies of the primary’s data and respond to queries that only need to fetch information.

This separation alone dramatically improves performance, because read-heavy traffic no longer competes with writes.

Keeping Data in Sync

Once multiple databases exist, the obvious question arises: how do they stay consistent?

That’s where replication strategies come in.

Synchronous Replication

In synchronous replication, when a write occurs, the system ensures that both the primary database and its replica record the change before confirming success.

This approach guarantees strong consistency. Every database reflects the same state at all times.

The tradeoff is speed. Writes take longer because the system waits for confirmation from replicas. If a replica is slow or unavailable, write operations can be delayed.

This model is chosen when correctness is non-negotiable — situations where even a brief inconsistency would be unacceptable.

Asynchronous Replication

Asynchronous replication takes a different approach.

Here, the primary database commits the write and immediately responds. Replicas update themselves afterward, often by periodically pulling new changes from the primary.

This makes the system much faster and more resilient under load. Writes are quick, and the system remains responsive even during traffic spikes.

The tradeoff is that replicas may briefly lag behind. For a short window, a read might return slightly outdated data.

In practice, this delay is acceptable for most applications, which is why asynchronous replication dominates real-world systems.

Why This Tradeoff Is Worth It

Modern systems are built around user experience. Speed matters more than perfect freshness in most scenarios.

A user scrolling a feed or viewing a product list does not notice a few milliseconds of delay in data synchronization, but they do notice slow page loads and laggy interactions.