Choosing a DR Topology for a 12 TB Order Platform Against a Committed RTO/RPO
A retail company is migrating its order-management platform to cloud. The platform runs on 40 virtual machines with a 12 TB relational database and peaks at 3,200 orders per minute. The business has committed to a 1-hour RTO and a 5-minute RPO. The platform team has proposed active-active across two regions 900 km apart, with synchronous commit on the database. Each order performs six sequential writes, and inter-region round-trip latency is 22 ms, so synchronous commit would add roughly 130 ms to every checkout; current p95 checkout latency is 640 ms against an 800 ms SLO. Thirty percent of database traffic is a nightly batch process that runs for five hours. Finance has approved the active-active design and expects delivery in one quarter. A separate team owns networking and has not yet provisioned cross-region private connectivity or confirmed compute quotas in the secondary region.
1. Does active-active with synchronous cross-region replication satisfy the stated RTO, RPO, and latency requirements? Show the arithmetic and recommend a topology, justifying the tradeoffs.
Read the worked answer
Run the arithmetic before the architecture. Six sequential writes multiplied by a 22 ms round trip adds roughly 132 ms to the critical path of every order. p95 checkout moves from 640 ms to about 770 ms, leaving essentially no headroom; normal jitter, retries, or a single degraded link pushes the SLO breach into production. Synchronous cross-region commit also couples availability to the inter-region link: when it degrades, writes block or fail, so you have traded a latency risk for an availability risk.
It does deliver RPO 0 and an RTO near zero on paper, but the stated requirement is RPO 5 minutes and RTO 1 hour. Synchronous replication is buying two orders of magnitude more durability than the business asked for, and paying for it with customer-visible latency.
Recommended topology: active-active at the stateless application tier, with a single-writer database in the primary region and asynchronous cross-region replication plus automated promotion. Asynchronous lag is normally sub-second to a few seconds, comfortably inside the 5-minute RPO. RTO comes from pre-provisioned secondary capacity, global load balancing or low-TTL DNS, replicated secrets and keys, and a rehearsed promotion runbook.
If a future requirement genuinely needs RPO 0, revisit with a consensus-replicated database or region-local data partitioning rather than naive synchronous commit. Confirm the network and quota prerequisites before committing to a date; those lead times may not fit the sponsor's quarter.
2. The finance sponsor insists the approved active-active design be delivered as specified. How do you handle the sponsor, and how do you treat the nightly batch workload within the chosen topology?
Read the worked answer
Do not argue the design abstractly; reframe it as a question of what the sponsor is actually buying. Present three concrete options with cost, p95 latency, and RTO/RPO for each: (a) synchronous active-active at roughly 770 ms p95 and a hard dependency on the inter-region link, (b) application-tier active-active with an asynchronously replicated single-writer database at roughly 640 ms p95 and an RPO measured in seconds, and (c) a warm standby with the same latency profile but slower, manual promotion. Option (b) usually satisfies the sponsor's underlying intent before the SLO becomes the constraint; the sponsor's real requirement is surviving a regional failure, not synchronous commit.
For the batch workload: pin batch writers to the primary region, route reporting reads to replicas, and make every batch job idempotent and restartable so it can be paused and replayed after a failover. Do not let a five-hour batch job run unprotected across the replication boundary, and do not let it be counted as part of the failover RTO; schedule it outside the failover rehearsal window.
Validation before go-live: a full failover game day that measures real RPO from observed replication lag and real RTO end to end, including DNS propagation, secret and key availability, quota consumption in the secondary region, reverse replication after failover, and a batch replay test. Report measured numbers, not design intent.