Multi-region failover

Normal day

Beginner

1. You open the app. Your device asks the switchboard where to go.
2. The main copy is healthy, so it sends you there.
3. You connect to the main copy of the app.
4. The app saves your change in the main database.
5. A copy of that change is sent to the faraway replica straight away.
6. The database confirms it’s saved.
7. All done. The spare copy has been quietly kept up to date.

Practitioner

1. The client resolves the app’s domain name.
2. DNS answers with the primary region’s address.
3. The client sends its request to the primary region.
4. The app writes to the primary database.
5. The change is replicated to the standby region.
6. The primary database acknowledges the write.
7. The response returns from the primary region.

Architect

1. DNS query for the app hostname.
2. Primary record returned because its health check is passing.
3. Request hits region A’s load balancer.
4. Write committed on the primary cluster.
5. Asynchronous cross-region replication, typically under a second of lag.
6. Commit acknowledged without waiting for the replica (async).
7. Response served; the standby is warm and its data is seconds behind.

Region outage

Beginner

1. The switchboard checks on the main copy, like it does every few seconds. No answer.
2. It checks the spare copy. That one’s healthy, so the switchboard flips over.
3. You open the app and ask where to go.
4. The switchboard sends you to the spare copy.
5. You connect to the spare copy, far away.
6. The replica becomes the main database and starts accepting changes.
7. Your data is there, almost exactly as you left it.
8. The app works again. A whole region failed, and you barely noticed.

Practitioner

1. A DNS health check to the primary region fails.
2. The standby passes its health check, so DNS fails over.
3. The client resolves the domain again.
4. DNS answers with the standby region’s address.
5. The client connects to the standby region.
6. The replica is promoted and handles the request.
7. The database returns the data.
8. The user is served from the standby region.

Architect

1. Health checks from multiple locations fail past the threshold.
2. Failover record activates; secondary becomes the answer.
3. New query (or the old answer’s low TTL expires).
4. Secondary record returned.
5. Traffic lands on region B; autoscaling ramps it up.
6. Replica promoted to writer; recent changes may be lost up to the replication lag (RPO).
7. Read/write served from the promoted cluster.
8. Recovery time is health-check detection plus DNS TTL plus scale-up.