How MongoDB Enables Active‑Active Multi‑Data‑Center Architectures

Active‑Active Demand

When organizations deploy applications across multiple data centers or regional clouds, they often aim for an "active‑active" architecture where all data‑center application servers handle requests simultaneously.

The goals of this architecture are to provide low‑latency local processing for global requests, maintain high availability even during regional outages, and achieve optimal resource utilization by parallel use of server resources across data centers.

Alternative Master‑DR Architecture

The alternative is a master‑DR (disaster‑recovery) setup where the primary data center handles traffic under normal conditions and the DR site remains idle until a failure occurs.

In a master‑DR model, data is replicated from the primary to the DR site so that the DR site can take over instantly when the primary fails.

Common Misconception

A frequent misunderstanding is that active‑active applications require a multi‑master database. This is incorrect because multiple masters can compromise data consistency and durability.

Database Requirements for Active‑Active Applications

Performance: Low‑latency reads and writes at the local data‑center node.

Durability: Replicated writes to multiple nodes to survive system failures.

Consistency: Reads must reflect the latest writes and be identical across regions.

Availability: The database must continue operating when a node, data center, or network fails, with recovery times of a few seconds.

Distributed Database Architectures

Three main architectures are used for active‑active deployments:

Two‑phase commit distributed transactions.

Multi‑master (sometimes called master‑less) databases.

Sharded (partitioned) databases with multiple primary shards.

Two‑Phase Commit Transactions

In a two‑phase commit, a single transaction updates all participating nodes synchronously, guaranteeing durability and consistency across nodes. However, this approach incurs significant performance penalties, increasing latency from milliseconds to seconds when nodes span multiple data centers, which is unacceptable for most client‑facing applications.

Multi‑Master Databases

Multi‑master databases allow writes to occur on any node, replicating changes to other nodes. While this seems ideal for active‑active, it introduces conflict‑resolution challenges because concurrent updates to the same record can produce divergent versions. Common conflict‑resolution strategies include "last write wins" or "most updates wins," both of which can lead to temporary inconsistencies.

Sharded (Partitioned) Databases

Sharding divides the dataset into partitions, each managed by a primary shard and its replicas. If a primary fails, a replica automatically takes over. By deploying at least one shard per data center and assigning a primary shard to each, applications can read and write locally while maintaining global consistency.

For example, a three‑data‑center deployment (NYC, LON, SYD) with three shards, each having three replicas, ensures that every data center holds a replica of every shard, allowing local writes to the shard’s primary and reads from any replica.

Database Architecture Comparison

The chart summarizes the trade‑offs of each architecture. Multi‑master may be easier to deploy but can suffer from read inconsistencies and potential data loss, whereas sharded databases generally provide the best balance of performance, consistency, and availability for most applications.

MongoDB for Active‑Active Applications

MongoDB exemplifies a sharded database. Its replica sets provide high availability for each shard, and zone sharding allows data to be partitioned by geographic region.

Key MongoDB features for multi‑data‑center deployments include:

Write Concern: Configurable durability guarantees by specifying the number of replica acknowledgments required before a write is considered successful.

Read Concern: Controls the consistency level of reads, such as

majority

or specifying

maxStalenessSeconds

to limit replication lag.

Causal Consistency: Ensures that reads reflect the order of preceding writes within a session, providing monotonic reads across distributed nodes.

Automatic Failover: MongoDB can detect node or data‑center failures and promote a new primary within 2–5 seconds, minimizing downtime.

Organizations such as eBay, YouGov, and Ogilvy & Mather already use MongoDB to achieve active‑active architectures.

Original link: https://dzone.com/articles/active-active-application-architectures-with-mongo