Designing Resilient, Highly Available Multicloud Solutions
Resilience framework
Start with business requirements: RTO (time to recover) and RPO (acceptable data loss). Map dependencies such as DNS, identity, interconnect, app tiers, and database, because a resilient database behind a single identity or network path is not resilient. Use availability domains and fault domains within a region, and multiple regions for disasters.
Patterns
- Within a region: Exadata RAC, Data Guard, Autonomous Data Guard, backups, and fault-domain-aware app tiers.
- Across regions or clouds: active-passive with Data Guard or GoldenGate; active-active only where the app can resolve conflicts and maintain consistency.
- Network: dual interconnects or interconnect plus VPN, diverse paths, and tested BGP failover.
- Operations: run game days, test restore rather than only backup, document manual steps, and protect break-glass access.
Worked example
An order app runs in Azure with Autonomous Database@Azure as primary. Requirements are RTO 15 minutes and RPO 5 minutes. The architect enables Autonomous Data Guard to a second Azure region, keeps a cross-cloud GoldenGate replica in OCI for cloud-exit risk, and uses dual private connectivity. DNS failover points to the standby app; identity federation has a tested break-glass path. A game day measures actual failover time and fixes a DNS TTL that breached the RTO.
Traps
Treating backups as DR; single interconnect; placing primary and standby in the same fault domain; ignoring identity or DNS as single points of failure; assuming RAC works across clouds; untested failover; split-brain in active-active designs.