Multicloud Data and Application Architectures
Multicloud Data and Application Architectures
This domain tests placement and movement of data and application tiers across clouds: latency, egress, consistency, replication, disaster recovery, and feature parity. The exam favors architectures that keep chatty traffic local and replicate only what the recovery objectives require.
Core rules and concepts
- Data gravity dominates. Put the application tier in the same cloud region as the database when the app makes many small queries. Oracle Database@Azure and Oracle Database@Google Cloud exist to remove cross-cloud latency for exactly this pattern.
- Cross-cloud replication is asynchronous by default for good reason. Synchronous replication across metros or clouds multiplies latency and failure coupling; use Oracle Data Guard or Oracle GoldenGate with documented RPO and RTO, and test failover.
- Egress and ingress costs, plus per-query latency, are architectural constraints. Batch or cache cross-cloud reads; avoid chatty microservice calls across an interconnect.
- Backups and DR must cross the right boundary. A backup in the same cloud region is not a multicloud DR strategy; verify restore procedures and key access in the recovery cloud.
- Feature parity is not automatic. Confirm that the database service, version, option, and tooling you need are available in the embedded service and region before committing.
Worked example
A retail application runs on Azure App Service and needs Oracle Database 19c with Data Guard. The team chooses Oracle Database@Azure Exadata in the same Azure region for the primary, keeping app-to-database traffic private and local. For DR, they use Data Guard to a standby in a second Azure region or an OCI region, accepting asynchronous replication and a measured RPO. They reject a single primary in a remote OCI region because every checkout transaction would cross the interconnect.
Traps
Stretching a single database synchronously across clouds; ignoring egress in cost models; assuming all Oracle options are available everywhere; designing DR without restore tests; and putting a chatty app in one cloud while the database sits in another "because the interconnect is fast".