Achieving Zero Downtime for MongoDB API: A Multi-Region Active-Active Approach on OCI

In the first part of this series, we explored how Autonomous Data Guard provides a leading failover mechanism for MongoDB workloads. However, as enterprise demands evolve towards “always-on” availability, even a minor failover window can impact global operations.

With this in mind, we will demonstrate a practical implementation of a bi-directional, active-active architecture for the MongoDB API on Oracle Cloud Infrastructure, designed to ensure continuous availability.

Traditionally, achieving a multi-region Active-Active setup for document databases has been fraught with challenges, primarily due to replication lag and complex conflict resolution in Raft-based systems. By leveraging Oracle GoldenGate alongside the Mongo API for Oracle, we can introduce a business-critical architecture that ensures zero downtime.

This solution is designed to solve the real-world pain points of global enterprises, where every second of downtime translates to lost revenue and diminished customer trust.

MongoDB developers can access a solution that provides:

  • Zero RPO & Zero RTO: Regional outages are no longer a disaster event. With both regions active, traffic is simply rerouted to an already-running environment. There is no “waiting for the database to switch roles.”
  • Data Integrity Without Rollbacks: Unlike standard Raft replication, which can lead to data loss during leader elections, Oracle’s architecture guarantees that every write is protected and synchronized, eliminating the business risk of lost transactions.
  • Operational Simplicity: You gain enterprise-grade resilience without the need to refactor a single line of your MongoDB application code.
  • Continuous Revenue Generation: By eliminating downtime typically required in traditional cloud regional failovers, your digital storefront remains open and transacting 24/7/365.
  • TCO (Total Cost of Ownership): By opting for Autonomous Database Serverless combined with the OCI GoldenGate service, organizations can significantly reduce their total cost of ownership (TCO); this architecture leverages true auto-scaling and a pay-per-use model, ensuring you only pay for the exact resources consumed during active replication and workload peaks.

While standard MongoDB deployments rely on replica sets and election-based failovers, our Active-Active solution provides structural advantages:

  1. Eliminating the “Elections” Bottleneck: Standard NoSQL databases require a “quorum” to elect a new leader during failure, causing a write freeze. Oracle GoldenGate allows both regions to be independent primary nodes with no elections and no freezes.
  2. Built-in Conflict Detection and Resolution (CDR): Oracle handles data collisions at the database level (e.g., “Latest Timestamp Wins”). This removes the burden from developers to write complex logic for multi-region data consistency.
  3. Global Performance: Serve users from the nearest geographic region while GoldenGate handles the sub-second bi-directional synchronization in the background.

The Technology Stack

To build a “zero downtime” environment, we utilize a specialized OCI stack:

  • MongoDB API for Oracle: Provides wire-protocol compatibility, allowing developers to use MongoDB drivers and tools while benefiting from the Oracle Database engine.
  • OCI GoldenGate Service: A fully managed, sub-second latency replication engine that captures data changes from the database redo logs without impacting application performance.
  • Autonomous AI ATP Database (AI ATP): A specialized version of Autonomous Database optimized for JSON documents and transactional workloads.
  • Conflict Detection and Resolution (CDR): An automated database-level feature that resolves data collisions (e.g., two people updating the same record in different regions) using “Latest Timestamp Wins” or custom logic.
  • OKE & HAProxy: Oracle Container Engine for Kubernetes provides the scalable app layer, while HAProxy manages the intelligent routing between regional database endpoints.

Architecture: Bi-Directional Flow

Unlike the Active-Passive model, this design utilizes two fully operational primary instances running in different regions (e.g., Ashburn and Phoenix).

Description: Two regions (Ashburn & Phoenix), each with OKE clusters and Autonomous AI ATP Databases, connected by bi-directional GoldenGate replication.

Step-by-Step Deployment:

The environment was built using a structured approach:

  1. Infrastructure: Provisioning VCNs, private subnets, and a bastion host for secure access.
  2. Database: Creating AI Autonomous Transaction Processing databases in the Phoenix and Ashburn regions as pairs, enabling GoldenGate deployment, and restoring data for MERN applications.
  3. GoldenGate Service: Deploying GoldenGate Service in Phoenix and Ashburn and configuring bidirectional replication and Automated conflict resolution
  4. Application: Deploying and Configuring Oracle Kubernetes Clusters and OCI Load Balancing service in Phoenix and Ashburn Regions
  5. Containerization: Packaging the MERN app with HAProxy and pushing the image to the OCI Container Registry (OCIR).
  6. Orchestration: Deploying to OKE containers using YAML manifests.
  7. Load Simulation: Configuring Apache JMeter to simulate real-world user traffic.

You may check the link that helps to create architecture in detail below:

Cross-Region Active-Active Resilience for Goldengate Setup Guide

Cross-Region Architecture Setup Guide

How it works:

  • Bi-Directional Replication: GoldenGate “Extract” processes capture changes from the redo logs in each region and deliver them to the peer region’s “Replicat” process.
  • Independent Primaries: Each database is a fully independent HA cluster. There is no “waiting for a leader election” or “read-only” state.
  • Loop Detection: The architecture includes intelligent filtering to ensure data replicated from Region A to B is not sent back, preventing infinite replication loops.

Testing

To prove this isn’t just theoretical, we conducted a rigorous “Failure Test” based on our recent architectural validations. We monitored the entire stack from the UI to the underlying replication logs.

Step 1: High-Load Simulation

We initiated a continuous write workload using Apache JMeter. We observed sub-second synchronization between the Ashburn and Phoenix regions.

Description: Application UI, replication logs, application logs, and OCI console monitoring.

Step 2: The Failure Event (Simulated Regional Outage)

While the load test was running at peak capacity, we terminated the Phoenix Autonomous AI ATP database.

  • Immediate Observation: The application logs briefly showed a connection error, but, thanks to HAProxy and the Active-Active setup, the very next request was instantly picked up by the Ashburn region. The MERN application was immediately switched to Ashburn
  • The Result: The JMeter test reported a near 0% error rate during the transition. The application stack did not need to be restarted. The transaction is running on the Ashburn Autonomous AI ATP DB, and all transactions are now captured via the GoldenGate Service on Ashburn

Step 3: Automatic Recovery and Catch-up

Once the Phoenix database was restored, the architecture demonstrated its self-healing nature:

  • Reverse Sync: GoldenGate identified all transactions that occurred in Ashburn during the outage.
  • Catching Up: Within seconds, Phoenix was “caught up” and synchronized, restoring full regional redundancy without any manual data reconciliation.
  • Application:: Jmeter workloads redirected to Phoenix region, which is the preferred connection on Haproxy when Phoenix Autonomous AI ATP database restored to available state

Conclusion: Setting a New Benchmark for Mission-Critical Continuity

This implementation of an active-active architecture using Oracle GoldenGate for the MongoDB API represents a fundamental shift in how we approach global data resilience.

You can now deploy document-based workloads that are truly “always-on,” transcending the traditional limitations of primary-standby models and election-based failovers.

Why This Matters for Your Business: In today’s global economy, a time gap during a regional failover is no longer acceptable. Our testing proves that, by moving the intelligence of high availability from the application layer to the Oracle Database engine, we can eliminate the downtime associated with application stack restarts and manual intervention.

The result is a self-healing environment that protects revenue, maintains customer trust, and ensures data integrity across continents.

A Scalable Future: By choosing the MongoDB API on OCI, you aren’t just getting a database; you are gaining an enterprise-grade ecosystem.

Whether you are scaling to handle seasonal traffic spikes or protecting against unpredictable regional outages, this architecture provides the most robust, low-latency, and zero-downtime foundation available in the cloud today.

As we have demonstrated through our live “Failure Tests,” the combination of developer-friendly MongoDB tools and the world-class power of Oracle GoldenGate is truly the gold standard for modern cloud applications.

Thank you for following our series on Mongo API for Oracle High Availability by Burak Akkus & Corina Todea

Resources

About the Authors

Burak Akkus is a member of Oracle’s Database Development team with 18+ years of experience in multi-cloud architectures, autonomous services, and NoSQL platforms. A specialist in end-to-end migrations and high-performance OCI deployments, Burak provides practical guidance on schema design and operational playbooks derived from extensive hands-on work with databases, OCI, and Azure.

Corina Todea is a product manager within the Oracle Database team with 22 years of expertise in enterprise software engineering and cloud-native architectures. Specializing in large-scale integrations, Kubernetes, and AI agents, Corina bridges the gap between product vision and real-world implementation, focusing on optimizing data-intensive systems for global scale.