Architecture scenarioMedium~10 minSystem Design Foundations Essentials / 3 of 15

Interview question

A database is healthy on writes but overloaded by read traffic. How would you use read replicas without creating confusing stale-data behavior?

Design read scaling with replicas and replication lag

Uses read replicas selectively while accounting for stale reads, read-after-write behavior, routing, failover, query cost, and replication health.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would first confirm that inefficient queries, missing indexes, or unnecessary reads are not the real bottleneck. Then I would route stale-tolerant work such as reports, catalog browsing, analytics, and background exports to a read replica. Writes continue on the primary. Reads that validate a write or must immediately show a user's change stay on the primary, or use a clear read-after-write strategy. The application needs separate connection roles so a critical query does not reach a lagging replica by accident.

Full answer below

Practice focus

Read scaling, replication lag, query routing, read-after-write consistency, reporting isolation, failover, observability, and data correctness.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Read replicas can add capacity and isolate reporting workloads, but an asynchronously updated copy is not interchangeable with the primary for every operation. Routing needs to reflect how fresh each read must be.
I would first confirm that inefficient queries, missing indexes, or unnecessary reads are not the real bottleneck. Then I would route stale-tolerant work such as reports, catalog browsing, analytics, and background exports to a read replica. Writes continue on the primary. Reads that validate a write or must immediately show a user's change stay on the primary, or use a clear read-after-write strategy. The application needs separate connection roles so a critical query does not reach a lagging replica by accident.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would define freshness per use case and make routing explicit in the data-access boundary. After a write, a session may temporarily read from the primary, carry a version that the replica must reach, or show the committed response directly while replication catches up. Long analytical queries can use a dedicated replica so they do not compete with interactive traffic. Replicas do not remove primary write limits, and they do not replace query tuning, pagination, caching, or purpose-built read models when those are the better fit.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would monitor replication lag by time and log position, replica query latency, error rate, connection saturation, and traffic distribution. If lag crosses a feature's budget, routing can fall back to the primary, serve a marked stale result, or reject the read based on risk; blindly moving all traffic back can overload the primary. Promotion and failover need a tested process that prevents two writable primaries and verifies application routing after topology changes. Backups remain necessary because replication faithfully copies accidental deletes and corrupt changes.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Sending every read to a replica regardless of freshness needs.
Adding replicas before fixing expensive queries and missing indexes.
Assuming replication is immediate or that a replica is a backup.
Failing all reads back to the primary without checking its capacity.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The application cannot explain which connection served a read.
A successful write can appear to disappear on the next screen.
Replica lag has no threshold or operational response.
Failover can leave multiple writable nodes or stale connection routing.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would you provide read-after-write behavior for one user?
What happens when replica lag suddenly increases?
Why is a read replica not a replacement for backups?

Continue the section

Next in System Design Foundations Essentials: Partitioning & Sharding

Step 4 of 15

Design data partitioning and sharding

Opening drill

Architecture scenarioMedium~10 minSystem Design Foundations Essentials / 3 of 15

Interview question

A database is healthy on writes but overloaded by read traffic. How would you use read replicas without creating confusing stale-data behavior?

Design read scaling with replicas and replication lag

Uses read replicas selectively while accounting for stale reads, read-after-write behavior, routing, failover, query cost, and replication health.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Read scaling, replication lag, query routing, read-after-write consistency, reporting isolation, failover, observability, and data correctness.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Read replicas can add capacity and isolate reporting workloads, but an asynchronously updated copy is not interchangeable with the primary for every operation. Routing needs to reflect how fresh each read must be.
I would first confirm that inefficient queries, missing indexes, or unnecessary reads are not the real bottleneck. Then I would route stale-tolerant work such as reports, catalog browsing, analytics, and background exports to a read replica. Writes continue on the primary. Reads that validate a write or must immediately show a user's change stay on the primary, or use a clear read-after-write strategy. The application needs separate connection roles so a critical query does not reach a lagging replica by accident.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would define freshness per use case and make routing explicit in the data-access boundary. After a write, a session may temporarily read from the primary, carry a version that the replica must reach, or show the committed response directly while replication catches up. Long analytical queries can use a dedicated replica so they do not compete with interactive traffic. Replicas do not remove primary write limits, and they do not replace query tuning, pagination, caching, or purpose-built read models when those are the better fit.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would monitor replication lag by time and log position, replica query latency, error rate, connection saturation, and traffic distribution. If lag crosses a feature's budget, routing can fall back to the primary, serve a marked stale result, or reject the read based on risk; blindly moving all traffic back can overload the primary. Promotion and failover need a tested process that prevents two writable primaries and verifies application routing after topology changes. Backups remain necessary because replication faithfully copies accidental deletes and corrupt changes.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Sending every read to a replica regardless of freshness needs.
Adding replicas before fixing expensive queries and missing indexes.
Assuming replication is immediate or that a replica is a backup.
Failing all reads back to the primary without checking its capacity.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The application cannot explain which connection served a read.
A successful write can appear to disappear on the next screen.
Replica lag has no threshold or operational response.
Failover can leave multiple writable nodes or stale connection routing.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would you provide read-after-write behavior for one user?
What happens when replica lag suddenly increases?
Why is a read replica not a replacement for backups?

Continue the section

Next in System Design Foundations Essentials: Partitioning & Sharding

Step 4 of 15

Design data partitioning and sharding

A database is healthy on writes but overloaded by read traffic. How would you use read replicas without creating confusing stale-data behavior?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

A database is healthy on writes but overloaded by read traffic. How would you use read replicas without creating confusing stale-data behavior?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section