Multi-Region DR for Card Authorization
A payments company processes 4 million card transactions per day from a three-tier Java application on Oracle. It is migrating to AWS with a regulatory requirement that primary and disaster-recovery data remain in us-east-1 and us-west-2. Tier-1 checkout has an RTO of 30 minutes and RPO of 5 minutes. The current cold-site DR takes 6 hours to validate and is tested annually. The team has six engineers, no 24/7 operations staff, and a 25% budget increase for resilience. The CIO wants active-active across both regions because "that is true high availability," but the lead architect is unsure. Transaction writes must remain consistent, and duplicate charges are unacceptable. The application also has a 12-year-old batch settlement job that runs at 23:00 UTC and cannot be replayed.
1. Recommend a DR strategy. Explain why it fits the RTO/RPO, team size, and budget better than the CIO's active-active proposal.
Read the worked answer
Recommendation: a warm standby across us-east-1 and us-west-2, not active-active. Run the full production stack in us-east-1 and a scaled-down but functional copy in us-west-2, with data replicated continuously and failover automated through runbooks and Route 53 health checks.
Reasoning: The 30-minute RTO and 5-minute RPO rule out the current cold site, because rebuilding and validating in 6 hours cannot meet either target. Active-active would meet the targets, but it requires conflict-free writes, global traffic steering, duplicate capacity, and 24/7 operational maturity. Six engineers without a follow-the-sun team would struggle to operate it safely, and the 25% budget increase is unlikely to cover two active regions. Warm standby avoids duplicate writes because only one region accepts traffic at a time. It still needs tested automation: infrastructure as code, database promotion, DNS failover, and quarterly game days. The tradeoff is a short outage during promotion, which is acceptable inside a 30-minute RTO.
2. How should the database and transaction consistency be handled? The company currently uses Oracle and is considering re-platforming.
Read the worked answer
Recommendation: decide the database platform before finalizing DR. If Oracle must remain, use Oracle Data Guard on EC2 across regions with synchronous or near-synchronous redo transport where latency permits, and document the actual measured RPO. If re-platforming is allowed, use Aurora Global Database: the secondary region has a typical RPO of about 1 second and can be promoted in minutes.
Reasoning: Duplicate charges come from two sources: retrying a transaction that was actually committed, and dual-writing to both regions. A single-writer failover model prevents the second problem. The application should use idempotency keys on payment authorization and a deduplication table, so a retry after failover cannot create a second charge. Avoid active-active writes unless the application has a proven conflict-resolution design; a database that accepts writes in two regions will eventually create reconciliation work. Aurora Global Database is simpler to operate than Data Guard, but re-platforming adds migration risk and changes the settlement batch job. Test the batch job in the secondary region and record whether it can run from a promoted replica.
3. The CIO later says the RTO must become 5 minutes. What changes, and what should you warn about?
Read the worked answer
Recommendation: a 5-minute RTO moves the design toward active-active or a hot standby with automated traffic shifting. Use Route 53 Application Recovery Controller or health-check-based failover, pre-warmed capacity in both regions, and continuous replication. If writes must stay single-region, automate promotion so no human approval is in the critical path, and keep a runbook for the rare case where automation fails.
Reasoning: A 5-minute RTO is mostly an automation and detection problem, not a backup problem. The team must detect regional impairment, decide to fail over, promote the database, and shift traffic within five minutes. That requires pre-delegated authority, alerting that avoids false positives, and regular failover tests. The warning is cost and complexity: hot standby roughly doubles run-rate for Tier-1, and active-active adds conflict resolution and global consistency work. Without 24/7 coverage, automated failover can make an outage worse if it triggers on a partial failure. Start with warm standby and measure actual failover time before promising 5 minutes.