Multi-region and failover
A second region buys two things: reads served next to the user, and a place to send writes when the first region goes dark. Each costs something, and the design is two numbers you agree on out loud: how stale a read may be, and how many writes a failover may lose.
What is the difference between RPO and RTO?
RPO, the recovery point objective, is how much acknowledged data you may lose when a region dies, usually stated in seconds of writes. RTO, the recovery time objective, is how long writes may be unavailable before the system takes them again. They pull against each other: waiting for a standby that is fully caught up protects the RPO and stretches the RTO, while promoting a lagging standby at once shortens the RTO and gives up the writes it never received. With asynchronous replication, the writes at risk are roughly the write rate times the replication lag.
Active-passive or active-active: which should I propose?
Start with active-passive unless the prompt forces more. One region takes every write and a standby in another region replicates it, so there is never a conflict to resolve, and the failover is a single, rehearsed decision. Active-active earns its complexity when users on two continents both need fast writes, and even then the usual shape gives each user or record a home region, so each record still has one writer at a time. Conflicts then appear only around a failover, and you detect them rather than silently keep the last write.
Why not fail over automatically the moment a health check fails?
Because a failed check is not proof the region is down, and because the standby may be behind. A few missed checks in a row keeps a network blip from moving your writes across an ocean. Then the promotion itself should be gated on how far behind the standby is: if it lacks more writes than the business agreed to lose, the right answer is to keep refusing writes until someone decides. Tools for database failover expose exactly this as a setting for the maximum lag a replica may have and still be promoted.
How does DNS affect failover time?
Clients cache a DNS answer for the record's TTL, so after you repoint the record, some clients keep sending traffic to the dead region until their cached answer expires. The DNS term of the recovery time is at most one TTL. That is why teams lower the TTL well before a planned failover, and why many designs put an anycast address or a global load balancer in front, so the switch does not depend on caches they do not control.
How do I keep reads fast in far regions without users seeing stale data?
Serve a read from the nearest region only when that region is fresh enough, and define fresh enough per read. For most reads a bound on replication lag is fine. For a user who has just written, the bound is their own write: carry the log position of their last write in the session, and serve the read only from a region that has reached it. Everyone else still reads locally, and only the few reads right after a write pay the trip to the primary.