Read replicas in managed relational databases

WHAT THIS TESTS 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.

A GOOD ANSWER COVERS 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.

COMMON WRONG ANSWERS 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.

LIKELY FOLLOW-UPS How does a read replica differ from a multi-AZ standby? What causes replication lag? Can a replica be promoted to primary?

ONE 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.