Read Replicas

Imagine you run a wildly popular news website. A few editors are publishing new articles (writes), but millions of users are refreshing the homepage to read them (reads).

If you point all that traffic at a single database server, the CPU will melt. The server will get so bogged down serving the millions of read requests that it won't have enough resources to process the editors' writes.

For many applications, the ratio of reads to writes is heavily skewed. Twitter, Facebook, and Wikipedia might have 100 or even 1000 reads for every single write.

To solve this scaling bottleneck, we use Read Replicas.

The Concept: Divide and Conquer

The idea is simple: instead of having one database do everything, you set up multiple database servers.

• You designate one server as the Primary (or Master).
• You set up several other servers as Replicas (or Slaves/Followers).

Here is the golden rule of this architecture: All writes MUST go to the Primary. Reads can go to ANY of the Replicas.

When an editor publishes an article, the application sends that INSERT statement to the Primary database. The Primary saves the data, and then immediately streams that change to all the Read Replicas. A fraction of a second later, all the replicas have a copy of the new article.

Now, when a million users hit the homepage, your application routes their SELECT queries to the Read Replicas. You can spread the load across 5, 10, or 50 replicas. The Primary is shielded from the massive read traffic and can focus entirely on processing writes quickly and safely.

How the Magic Happens: Replication

How does the data actually get from the Primary to the Replicas? It uses the Write-Ahead Log (WAL) or replication logs.

When the Primary executes a transaction, it records it in its log. The Replicas are constantly connected to the Primary, listening to this log. As soon as a new entry appears, the Replica downloads it and "replays" the exact same transaction on its own disk.

There are two main ways this happens:

1. Asynchronous Replication (The Standard)

In asynchronous replication, the Primary saves the data to its own disk, tells the user "Success!", and then sends the data to the Replicas in the background.

• Pros: Blazing fast. The Primary doesn't wait for anyone.
• Cons: There is a slight delay (Replication Lag). If the Primary suddenly blows up before it sends the data to the replicas, that data is permanently lost.

2. Synchronous Replication (The Safe Route)

In synchronous replication, the Primary gets the write, sends it to the Replicas, and waits for the Replicas to say "Got it!" before telling the user "Success!".

• Pros: Perfect data safety. Even if the Primary dies, you know the data is safe on the Replicas.
• Cons: Slow. Your write speed is limited by the network latency and disk speed of your slowest replica.

Most consumer applications use Asynchronous replication, accepting a tiny risk of data loss for massive performance gains.

The Hidden Trap: Replication Lag

Read replicas introduce a notoriously tricky problem for software engineers: Replication Lag.

Because asynchronous replication takes a few milliseconds (or even seconds under heavy load), the Replicas are always slightly behind the Primary.

Imagine a user updates their profile picture.

1. The app sends the UPDATE to the Primary.
2. The Primary says "Success!"
3. The app redirects the user to their profile page.
4. The profile page does a SELECT from a Read Replica.
5. The Replica hasn't received the update from the Primary yet!

The user sees their old profile picture and gets confused, thinking the save didn't work.

How to solve this?

Engineers use a pattern called "Read-Your-Own-Writes". The application logic is programmed to know: "If this specific user just wrote data, force all their read queries to go directly to the Primary for the next 5 seconds. Let everyone else read from the Replicas."

Failover and High Availability

While the main purpose of Read Replicas is scaling performance, they offer a massive secondary benefit: High Availability.

If your Primary database server suffers a catastrophic hardware failure, your application can't write any data. But, because you have Read Replicas sitting right there with a near-perfect copy of the data, your system administrators (or automated tools) can instantly promote one of the Replicas to become the new Primary.

This process is called Failover, and it turns a potentially catastrophic outage into a minor 30-second hiccup.

Summary

• Applications often have heavily skewed read-to-write ratios.
• Read Replicas scale database performance by offloading read queries to secondary servers, freeing the Primary server to handle writes.
• Data is kept in sync via Replication, where the Primary streams its transaction logs to the Replicas.
• Asynchronous replication is fast but introduces Replication Lag, meaning replicas might serve slightly stale data.
• Applications must implement strategies like "Read-Your-Own-Writes" to handle lag.
• Replicas provide High Availability; if the Primary dies, a replica can be promoted to replace it.