TL;DR: A traditional RDS Multi-AZ DB instance synchronously replicates to a non-readable standby and automatically fails over. Typical failover is 60–120 seconds, with workload-dependent variation, not a guaranteed outage ceiling. Applications fall over during failover when they treat the DB endpoint as permanently reachable instead of retrying through a brief outage.
How to approach it
Separate the two promises cleanly: data safety versus service continuity. Then explain why a correctly functioning Multi-AZ setup can still take your application down for a minute or two, because that paradox is the whole question.
A strong answer
What a traditional Multi-AZ DB instance does. The primary instance replicates synchronously to a standby in another AZ. On primary failure (host loss, AZ impairment, maintenance), RDS promotes the standby and moves the DNS endpoint to it. Synchronous replication means committed transactions are on both copies, so failover loses nothing acknowledged. That is a durability and recovery-time feature.
What it does not do. Failover takes time. DNS must update, and clients may cache the old address or retain old connections; the standby must promote, and clients holding pooled connections find every socket dead. AWS describes 60–120 seconds as typical for this deployment, with larger transactions or recovery work able to extend it. The separate Multi-AZ DB cluster product has two readable standbys and different failover behavior. Identify the product before promising timing or read capacity. DB-instance failover and Multi-AZ deployment types.
So why did the application "fall over" rather than degrade? Because most applications treat connection failure as fatal:
- Pools abort on first error. A connection pool that marks itself broken on one reset requires restarts or long timeouts to recover. Pools should validate-and-replace connections lazily after errors.
- No retry budget on transient failures. One failed query during promotion should be retried with backoff if it was read-only or idempotent; instead the request 500s, upstream retries amplify, and the app converts a 60-second database blip into a ten-minute error storm.
- Long-lived TCP assumptions. Services that open a connection at boot and assume it forever die at promotion and stay dead until redeployed.
- DNS caching. JVM DNS caches, custom resolvers and sidecars pinning the old IP extend the window well past the provider's own.
The fix list is short and worth stating as commitments: idempotent writes where possible so retries are safe, aggressive-but-bounded retry with exponential backoff and jitter around database errors, connection pools configured with sane validation and reconnect behaviour, and health checks that mark the service degraded rather than dead while the database is briefly gone. Then rehearse: trigger failover in staging monthly (aws rds reboot-db-instance --db-instance-identifier STAGING_DB_ID --force-failover) and measure what the application actually experiences, because the gap between belief and reality here is always surprising.
The senior framing: Multi-AZ automates promotion, reducing recovery work without providing a hard upper bound on application outage. Whether those tens of seconds are invisible depends entirely on client-side engineering the database product cannot do for you.
What interviewers probe next
"Why not just use Aurora?" Aurora's storage layer replicates at six endpoints across three AZs and fails over faster, but the client-side truths are identical: connections break and retries decide whether users notice.
"Read replicas versus the standby?" Different purposes: replicas scale reads (and lag, which introduces staleness bugs); the traditional DB-instance standby supports failover rather than reads. Multi-AZ DB cluster standbys can serve reads. Confusing them in design reviews is common.
"How would you prove the fix works?" Scheduled failover drills with dashboards measuring user-visible error rate, not just database metrics. If nobody saw anything, you passed.
Common mistakes
Answering that Multi-AZ means high availability, full stop. It reduces downtime; it does not eliminate it, and the difference lands on the application.
Blaming the provider because failover took ninety seconds. That can be within typical observed timing. Compare the actual outage with the documented product behavior and application recovery objective rather than treating typical timing as a contract.
Never drilling failover before production needs it. The first real promotion is the worst possible time to learn how your pools behave.