Practice the vocabulary of scaling database reads with a synchronized replica.
0 / 5 completed
1 / 5
At standup, a dev mentions directing read-heavy queries to a copy of the database kept in sync with the primary, so the primary is freed up to handle write traffic. What is this copy called?
A read replica is a copy of the database kept continuously in sync with the primary, to which read-heavy queries can be directed, freeing the primary database to handle write traffic without competing for the same resources. A one-time backup has no ongoing synchronization, so it quickly becomes stale and unsuitable for serving live read queries. This read-write separation is a common pattern for scaling a database's read capacity well beyond what a single primary instance could handle alone.
2 / 5
During a design review, the team wants the application to account for the fact that a read replica might lag slightly behind the primary, so a query immediately following a write doesn't read stale data. Which capability supports this?
Handling replication lag means the application accounts for a read replica potentially being slightly behind the primary, such as by routing a read-after-write query directly to the primary instead of a lagging replica, so the user doesn't see stale data immediately after making a change. Assuming a replica is always perfectly instantaneously synchronized ignores that replication is inherently asynchronous and carries some delay. This lag-awareness is an essential nuance of designing an application around read replicas correctly.
3 / 5
In a code review, a dev notices the application's database client automatically routes a write query to the primary and a read query to one of several available replicas. What does this represent?
Read-write query routing automatically directs a write query to the primary database and a read query to one of the available read replicas, distributing load according to each query's actual requirement. Sending every query exclusively to the primary defeats the purpose of having replicas available to absorb read traffic in the first place. This routing logic is typically handled by the database client or a proxy layer, so individual application code doesn't need to manually decide where each query should go.
4 / 5
An incident report shows a report-generation query read from a read replica that was significantly behind the primary due to a replication delay, producing a noticeably outdated report with no indication of the staleness. What practice would prevent this?
Monitoring replication lag and avoiding, or clearly flagging, a read from a replica that's fallen significantly behind prevents a report or query from silently returning noticeably outdated data with no indication anything was stale. Reading from any available replica with no lag awareness risks exactly this kind of silent staleness. This monitoring is especially important for a workload, like a report, where a large unnoticed staleness gap could mislead whoever relies on that data.
5 / 5
During a PR review, a teammate asks why the team routes read traffic to a replica instead of simply sending every query, both reads and writes, to the primary database. What is the reasoning?
Sending every query exclusively to the primary concentrates both read and write load on a single database instance, which eventually becomes a scaling bottleneck as traffic grows. Distributing read-heavy traffic across one or more replicas frees the primary to focus on writes while replicas absorb the read load. The tradeoff is the added application complexity of handling replication lag correctly, particularly for a read that needs to immediately reflect a very recent write.