Multi-Region Failover with a Data Residency Constraint
A healthcare-adjacent startup must keep primary customer data in one country (Region A) by regulation, but wants a disaster-recovery posture. Leadership proposes active-active across Region A and Region B in another country, with synchronous replication, claiming 'five nines and no data loss.' The database is a single-writer relational store; synchronous cross-border replication would add roughly 120 ms round-trip latency to every write. The compliance team notes that replicating identifiable data to Region B may itself violate the residency rule unless data is anonymized first. The startup has 6 engineers and a 99.9% availability target, not 99.999%.
1. Assess the active-active synchronous proposal against the residency rule, the latency budget, and the team's actual availability target.
Read the worked answer
The proposal fails on three counts:
- Residency: synchronous replication of identifiable data to Region B likely breaches the rule. Unless data is anonymized before leaving Region A, active-active across borders is non-compliant. Anonymization changes the architecture (you replicate derived data, not raw records), which is a different design than proposed.
- Latency: a single-writer store with 120 ms synchronous cross-border round-trips adds that latency to every write, and a single writer cannot be active in two regions anyway. True active-active requires conflict resolution the relational store does not provide.
- Over-engineering: the target is 99.9%, not 99.999%. Chasing five nines with cross-border sync spends engineering effort and risk on availability the business did not ask for.
A compliant design is active-passive within Region A (multi-AZ) for the 99.9% target, with a warm standby in Region B holding only anonymized or aggregated data for analytics/DR of non-regulated components. Failover for regulated data stays inside the country.
2. Given only 6 engineers, propose a realistic DR approach that meets 99.9% and the residency rule, and state what you would explicitly not build.
Read the worked answer
Build: multi-AZ deployment inside Region A with automated failover, regular tested backups, and a documented runbook. Add a pilot-light or warm standby in Region B for stateless front-end and anonymized derived data only, so the regulated store never leaves the country. Define RTO/RPO explicitly (e.g., RTO 1 hour, RPO 15 minutes) and test failover quarterly.
Do not build: cross-border synchronous replication of identifiable data, active-active multi-writer on the relational store, or a five-nines program. With 6 engineers, an untested active-active design is more likely to cause an outage than prevent one. The honest trade-off is that a full regional loss of Region A means a longer RTO for regulated data; state that risk to leadership rather than pretending the design removes it. Document the residual risk and the regulatory basis for keeping data in-country.