Active-passive, RPO and RTO

In active-passive, one region serves all the traffic. A second region holds a copy of the data, kept current by asynchronous replication, plus some standby compute. When the primary fails, you promote the copy and send traffic to it. Two numbers describe any such design. RPO (recovery point objective) is how much data you can afford to lose, measured in time. RTO (recovery time objective) is how long you can be down.

The big idea

Standby regions come in temperatures. A hotter standby costs more and recovers faster.

Two other tools matter as much as the standby. DNS failover points a health-checked record at the secondary when the primary fails. Keep TTLs low, around 30 to 60 seconds, but expect some clients and resolvers to cache longer. Anycast-based options, such as AWS Global Accelerator, shift traffic without waiting on DNS caches.

Walking through it

RPO is set by replication lag. With asynchronous replication, the writes you lose are the ones made in the seconds before the failure:

write rate:                      2,000 writes/s
typical cross-region lag:        ~0.5 s (can spike to tens of seconds under load)
writes lost on sudden failover:  2,000 x 0.5 = ~1,000 writes in the good case
during a lag spike to 30 s:      2,000 x 30  = 60,000 writes

Some of those writes were already acknowledged to users, so they can't be rolled back quietly. Plan to reconcile them, for example by replaying them from the old primary once it is reachable, or from a durable queue upstream.

RTO is the sum of every step, and people dominate it:

detect the regional problem (alerts, confirmation)      5 min
decide to fail over (on-call escalation, judgment)     10 min
promote the replica, scale up the standby               5 min
shift traffic (60 s DNS TTL, plus slow resolvers)       5 min
verify and watch                                        5 min
                                                RTO ~ 30 min

The biggest lever on RTO is usually automation and a decision made in advance, not faster technology. A runbook that says "if the error rate in region X exceeds 25% for 10 minutes and the provider confirms a regional event, fail over without further approval" removes the slowest step.

Common mistakes

• Treating RPO as zero. Asynchronous replication always has some lag, and that lag is data you can lose.
• Expecting RTO to be a technology problem. Detection and decisions usually take longer than the switch itself.
• Forgetting resolver caches. A low TTL doesn't guarantee that every client moves right away.

Check yourself

1. With 2,000 writes per second and 0.5 seconds of replication lag, how many writes can a sudden failover lose?

   About 1,000 writes, which is 2,000 × 0.5.

2. Which part of the RTO usually dominates, and what shrinks it most?

   Detection and the decision to fail over. A pre-approved runbook with automation shrinks it most.

Key takeaways

• RPO is the data you can lose. With asynchronous replication, it equals the lag.
• RTO is the time you are down, and most of it is human steps.
• A hotter standby recovers faster, but it costs close to double.
• Pre-approved runbooks and automated failover shorten RTO more than faster hardware does.

Further learning

Next: active-active and home regions, for designs where every region serves traffic.