Read replicas in managed relational databases
scaling reads and replication basics.
a read replica is an async copy of the primary that serves read-only queries, offloading the primary and scaling read-heavy workloads; expect replication lag.
What's really being asked
The interviewer wants to confirm you understand a read replica as a read-scaling tool with eventual consistency, and that you do not conflate it with a high-availability failover standby.
The full answer
A read replica is a copy of a primary relational database that receives changes from the primary through asynchronous replication and serves read-only queries. Its primary purpose is to scale read throughput: by directing select queries to one or more replicas, you offload work from the primary, which is then free to focus on writes, and you can add replicas to handle growing read volume. Because replication is asynchronous, replicas can lag the primary by a small amount, so they may return slightly stale data; the application must tolerate this eventual consistency for the reads it sends there. This is distinct from a synchronous high-availability standby, such as a multi-AZ deployment, whose job is automatic failover rather than serving traffic, and which stays in sync but is not normally readable. A common use case is a read-heavy application, for example a content site or analytics dashboard, where the bulk of traffic is reads: you route reporting and browse queries to replicas while writes go to the primary, often placing replicas in other regions to serve geographically distributed readers with lower latency.
The mistakes people make
Describing a read replica as an automatic failover target; that is the standby's role. Assuming replicas are always perfectly consistent with the primary, ignoring replication lag. Sending writes to a replica, which is read-only.
What usually comes next
How does a read replica differ from a multi-AZ standby? What causes replication lag? Can a replica be promoted to primary?
A concrete example
A news site routes article reads and trending queries to two read replicas while comments and publishes write to the primary, so a traffic spike is absorbed by adding replicas, with readers tolerating a sub-second lag.
Interview question
An application's read traffic far exceeds its writes and is slowing the primary. How does a read replica help, and what must the app tolerate?
- a.It is a synchronous failover standby and serves no live traffic
- b.It serves read-only queries to offload the primary, but reads may be slightly stale due to lagCorrect
- c.It guarantees reads are always perfectly up to date with the primary
- d.It accepts writes too, doubling write capacity with no consistency cost
Why? this is the answer
A read replica offloads reads from the primary, scaling read-heavy workloads, but asynchronous replication means replicas can lag and return slightly stale data. It is read-only and not a failover standby.
Just read this? Test yourself on what you have been reading.
Read the original → en.wikipedia.org
- #databases
- #read-replica
- #scaling
- #replication
- #cloud
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on databases — each one lists the topics its interview covers.
See open roles