Read replica vs Multi-AZ in RDS

WHAT THIS TESTS Interviewers want to see that you separate two distinct concerns: high availability versus read scalability. Many candidates conflate them because both involve copies of the database.

A GOOD ANSWER COVERS Multi-AZ provisions a synchronous standby instance in a second availability zone. Writes commit to both before acknowledging, so on a primary failure RDS promotes the standby and updates the DNS endpoint automatically, usually within a minute or two. That standby serves no application traffic; it exists purely for failover and durability. A read replica is an asynchronous copy in the same or a different region that your application reads from directly via its own endpoint. It offloads read-heavy traffic from the primary but exhibits replication lag, so reads can be stale. You would use Multi-AZ for resilience, read replicas for scaling reads, and both together for a system that needs failover and high read throughput.

COMMON WRONG ANSWERS Claiming the Multi-AZ standby answers read queries, treating read replicas as a failover or backup mechanism, or assuming replicas are synchronous and always consistent. Another mistake is forgetting that replica promotion is manual and breaks replication.

LIKELY FOLLOW-UPS How does failover affect open connections. What is replica lag and how do you monitor it. Can a read replica be promoted to a standalone primary. How does Multi-AZ differ from the newer Multi-AZ cluster with readable standbys.

ONE CONCRETE EXAMPLE An e-commerce site runs a primary with Multi-AZ so a zone outage triggers automatic failover without data loss. Black Friday read traffic for product pages overwhelms the primary, so they add two read replicas behind a reader endpoint, routing catalog browsing there while checkout writes stay on the primary.