RPO Five Minutes Without Dual Writes

Two different problems are being solved and they must not share a solution.

Problem 1 - disaster recovery of the system of record. Use Autonomous Data Guard with a cross-region standby inside the EU (for example a second German or Netherlands OCI region). It replicates continuously at the storage/redo level, so RPO is seconds, not minutes, and failover is a managed operation measured in minutes - which satisfies both targets. The Data Pump nightly export does not come close and should be retained only as a logical backup against corruption, not as the DR mechanism. Critically, the standby stays in OCI; Autonomous Data Guard is an OCI-to-OCI capability and does not extend to an Azure-hosted database, which is why the CTO's constraint about Azure is consistent with the design.

Problem 2 - analytical read locality. Use OCI GoldenGate to replicate the booking schema to an analytics target. Extract from the Data Guard standby rather than the primary so the extract load does not compete with booking traffic. The cheapest correct target is often Autonomous Data Warehouse in OCI rather than an Oracle database on Azure VMs: the dashboards already run in Azure and cross the interconnect in single-digit milliseconds, so a second copy inside Azure buys little and doubles the operational surface. Keep the extracted tables narrow - booking events and reference data - not the whole OLTP schema.

The no-dual-write rule is respected because GoldenGate is the only writer to the analytics target and the application only ever writes to one primary. Any design where the app writes two databases recreates the conflict resolution problem the CTO vetoed.

Order of operations:

1. Declare disaster after confirming the failure is regional, not a connectivity blip from Azure. Check the OCI status feed and the interconnect state - do not fail over because the interconnect dropped.
2. Confirm standby lag before promoting. If the standby is far behind, you are choosing between RPO breach and data loss; record the decision and by whom.
3. Perform the Data Guard failover to the standby region. The old primary is fenced by the service; do not attempt to bring it back as a writer.
4. Repoint the application. This is where the design is most likely to break. The booking service connects to a private endpoint in the primary region's VCN, not to a global anycast name. After promotion, the endpoint exists in a different VCN with different private IPs, and the interconnect path changes. Publish a stable CNAME in a DNS zone you control, resolving to a regional private load balancer in front of the database, and set TTL to 30-60 seconds. Otherwise step 4 is an application configuration change and a redeploy in the middle of an outage.
5. Drain and recreate AKS connection pools. In-flight transactions are lost; the booking service must surface a retryable error rather than a hard failure.
6. Wallet and TLS: download the wallet for the new region and confirm client trust before the drill, not during the incident.
7. GoldenGate: the extract process in the failed region is gone. Restart extraction from the new primary and accept that the Azure analytics copy has a gap; decide in advance whether to backfill or accept it.

Most likely break: DNS and connection strings, followed by the assumption that the standby's service name matches the primary's. Test both by actually failing over, quarterly.

Residency is satisfied - the copy remains in the EU - but residency is not the only obligation, and an architect who treats it as the whole answer creates a compliance incident.

Conditions to impose:

• Data minimisation: replicate only the columns dashboards actually need. Booking reference, route, timestamps, and amounts do not require passenger names or contact details. If a join truly needs identity, replicate a tokenised surrogate key and resolve identity in the system of record.
• Access control: the Azure-side reader account must be granted read on the analytics schema only, never on the source; Azure RBAC and Entra groups gate who can query it, and the same quarterly access review applies.
• Retention: the analytics copy is a derived store, so define how long it keeps history and delete on schedule. A derived store that quietly accumulates seven years of PII is a finding waiting to happen.
• Erasure handling: when a subject exercises erasure, the source deletes the row but the replica will not, because GoldenGate replicates inserts and updates, not policy. Agree the mechanics up front - either exclude the PII columns so erasure never has to propagate, or run a documented purge job against the replica.
• Encryption and keys: encrypt at rest with keys held in a vault the analytics team does not administer, and document which cloud holds the root of trust.
• Audit: log who queries the replica and retain those logs for the compliance period; dashboards are usually built once and queried forever.

The cleanest resolution is the one that also fixes the cost problem: keep the replica PII-free by design, so most of these obligations become easy to evidence.