Read Replicas

Think of a read replica like an extra cashier lane that can look up orders but cannot change inventory. Interviewers love this topic because it tests whether you understand both scaling and consistency.

Question: What are read replicas in SQL databases, and why would you use them?

Answer: A read replica is a copy of the main database that receives changes from the primary database and is used mostly for SELECT queries. It helps spread read traffic across more machines so the primary can focus on writes. The trade-off is that replicas can lag behind, so they may temporarily return older data.

Interview-Ready Answer: I’d say a read replica is a secondary database that continuously receives changes from the primary and serves read-only traffic. I use replicas to scale reads, lower load on the primary, and sometimes place data closer to users. The main thing I watch is replication lag: after a write, a replica may not show the new value immediately, so for read-after-write paths I either query the primary or use a consistency strategy that guarantees freshness.

What it is

A read replica is a database copy that is kept in sync with the primary database. The primary accepts writes; the replica is usually read-only. The key idea is simple: instead of forcing every dashboard, report, and product search to hit one busy server, you spread those reads across replicas.

How it works under the hood

1. The application writes to the primary database. A primary is the main writable copy.
2. The primary records each change in a replication log. In PostgreSQL this is the WAL (Write-Ahead Log), and in MySQL it is typically a binary log. A log is just an ordered record of changes.
3. The log is shipped over the network to the replica.
4. The replica replays those changes on its own storage so its data matches the primary as closely as possible.
5. Your app routes SELECT queries to the replica, while INSERT/UPDATE/DELETE stay on the primary.
6. If the primary fails, an operator or automation can promote a replica, meaning it becomes the new primary.

When and why to use them

Use read replicas when reads are much heavier than writes, like product catalogs, analytics dashboards, feed pages, or “my recent orders” screens. They are also useful for geographic latency: a replica closer to Europe can answer European reads faster than a primary in another region.

What they do not solve

Replicas do not make writes faster. Every write still lands on the primary, and the primary must ship those changes to each replica. So replicas reduce read pressure, but they do not magically remove a write bottleneck.

Also, replicas do not guarantee fresh data unless the system uses synchronous replication. In the more common asynchronous setup, the primary commits first and replicas catch up a moment later. That delay is called replication lag.

Read replicas vs other performance tools

A helpful rule: indexes make one database query cheaper, replicas give you more databases to answer reads, and caches skip the database entirely for hot data.

Performance and complexity notes

From an application perspective, a read query on a replica is still usually O(1) for lookup work, but end-to-end latency depends on network distance, replica load, and disk speed. Replication itself adds extra work to the primary: every change must be streamed to each replica, so write amplification grows with the number of replicas. In practice, teams often start with 1–2 replicas and add more only when they see sustained read pressure and acceptable lag.

Important edge cases

• Read-after-write bug: a user updates their profile, then immediately reloads it from a replica and sees the old name.
• Replica lag: reports and dashboards may be a few hundred milliseconds or even several seconds behind during spikes.
• Routing mistakes: sending writes to a replica causes errors because replicas are read-only.
• Mixed snapshots: if one report hits different replicas at different times, it can combine different versions of the data.

Memory hook: Primary is the cashier, replicas are the look-up desks. They can answer questions fast, but only the cashier changes the receipt.

Real-World Story: Imagine a checkout service for an online store. The primary database stores orders, payments, and inventory changes. The app sends the customer’s “order history” page and the admin dashboard to read replicas so thousands of users can browse without slowing down checkout. A common outage happens when the team assumes a replica is instantly fresh: right after payment succeeds, the app asks a replica whether the order exists, but replication is 2 seconds behind. The user sees “payment pending,” support tickets spike, and logs show the order row exists on the primary but not yet on the replica. The fix is to route critical read-after-write checks to the primary, or wait for confirmed replication before showing the final success state.

Follow-up & Tricky Questions:

• How do you route traffic between primary and replicas? Usually the app or a proxy sends writes to the primary and read-only queries to replicas. Many teams also keep a short list of queries that must always read from the primary, like post-payment confirmation.
• What is replication lag and why does it matter? Lag is the delay between a write on the primary and the same change becoming visible on a replica. It matters because stale data can cause wrong UI states, bad decisions in dashboards, or duplicate actions.
• Does a read replica improve write performance? Not directly. It helps the primary by offloading reads, but every write still lands on the primary and must be copied to the replicas.
• How do replicas interact with transactions? A replica can serve a transaction snapshot, but that snapshot may be older than the primary. If your business logic needs the latest committed write, a replica may be the wrong place to read from.
• When would you choose an index instead of a replica? If one slow query is the problem, an index is usually the first fix because it speeds up that query on the existing database. A replica is for broader read scaling, not for fixing a single bad query.
• Can I safely run reports on a replica? Yes, if slightly stale numbers are acceptable. For financial reconciliation or real-time inventory, stale reads can be dangerous.
• Is a replica the same as a backup? No. A replica is for serving live traffic; a backup is for recovery after corruption, accidental deletes, or disaster.
• Can replicas be used for failover? Yes. Many systems promote a healthy replica to become the new primary if the old one dies, but that requires careful automation and health checks.

• Will adding more replicas always help? Not forever. More replicas increase network and replication overhead on the primary, and at some point the bottleneck moves to the write path or the replication pipeline.
• Do replicas guarantee the latest committed data? No, not in asynchronous replication. That is the most common gotcha in interviews.
• Can I send every SELECT to a replica? Usually yes, but not if the query must see the result of a just-finished write or must be strongly consistent.

Common Mistakes:

• Thinking replicas fix slow queries: they spread load, but a bad query is still bad. The correction is to add the right index or rewrite the query first.
• Ignoring stale reads: replicas can be behind. The correction is to keep read-after-write flows on the primary or wait for freshness.
• Using replicas as backups: replicas are live systems, not recovery copies. The correction is to keep separate backups and restore testing.
• Assuming more replicas always mean faster writes: writes can get slower because the primary must ship changes to each replica. The correction is to watch replication overhead and lag.

Memory Hook: “Primary changes the truth; replicas repeat the truth later.”

Cheat Sheet:

• Read replicas scale SELECT traffic.
• Primary handles all writes.
• Replication lag means replicas can be stale.
• Great for dashboards, feeds, and geo-local reads.
• Not a replacement for indexes or caching.
• Watch read-after-write consistency carefully.

Practice Tasks:

• Create a table, insert data, and run a read-only transaction to verify read-only behavior.
• Identify one query in an app that can safely go to a replica and one that must stay on the primary.
• Compare the impact of adding an index versus adding a read replica for a slow reporting page.