Multi-Region Deployment Paradigm
Multi-region Atlas deployments set up cluster nodes across multiple regions (as defined by the cloud providers). Multi-region deployments enhance protection in the case of a regional outage by automatically rerouting traffic to a node in another region for continuous availability and a smooth user experience. Multi-region deployments can also enhance performance and can help meet compliance requirements for data sovereignty, such as the EU's General Data Protection Regulation (GDPR) law.
A multi-region deployment might have multiple regions within the same geography (a large area like a continent or country), a single region in each of several geographies, or multiple regions in multiple geographies.
Multi-region deployments can exist with a single cloud provider or multiple cloud providers. To learn about multi-cloud deployments, see Multi-Cloud Deployment Paradigm.
To learn how to configure multi-region deployments and learn about the different types of nodes you can add, see Configure High Availability and Workload Isolation in the Atlas documentation.
Note
Multi-region deployments are available only for M10 dedicated
clusters and larger.
Multi-Region Deployment Strategies
Consider the 3 deployments in the following image:
The first example shows a deployment to multiple regions in the same geography.
This is a good solution if you have an application that has users primarily
located in a single geography (in this case, the U.S.). You create a multi-region
deployment in three regions within the U.S. This ensures low latency,
since all regions are within the same geography, while also offering high
availability if there's a regional outage on one of the nodes
(for example, if us-east-1 goes down).
The second example shows a deployment to a single region in each of multiple geographies. This is a good option if your application requires high availability for users in multiple geographies but you are willing to trade slightly higher latency for lower costs. You create a multi-region deployment with a region located in the U.S. Europe, and Asia. This is also a good strategy for complying with local regulations like GDPR.
The most complex example of a multi-region deployment has multiple regions in multiple geographies, ensures the highest level of availability with a single provider. If your application requires the very highest level of availability and lowest latency, consider a Multi-Cloud Deployment Paradigm.
Within these broad deployment strategies, there are additional configurations to meet your more specific needs. The following use cases outline specific examples that might meet your own needs.
5-Node, 3-Region Architecture
If you have a mission-critical application that requires both high availability and low latency, you need to deploy your MongoDB nodes and your application in multiple regions. Depending on your users' locations, you might need to deploy to regions in several different geographies.
To achieve this level of availability and latency, we recommend an architecture that consists of a minimum of 5 nodes spread over at least 3 regions. This architecture provides high availability in at least 2 regions. If a node goes down, the traffic can be served from the same region to ensure the same latency on the primary region.
Notes and Considerations
Deploy your application servers in each region that MongoDB nodes are deployed. This gives you the ability to route read requests to the in-region node, which reduces the response time to your users, and offloads requests from the primary node. Write requests are always directed to the primary.
Use private endpoints to connect to the cluster, and VPC peering between your application server VPCs. VPC peering ensures that if a network connection is broken or Atlas in that region goes down, the application tier can still route to the primary node, first over the VPC peering, and then over the private endpoint.
This architecture has the highest cost due to network traffic between regions and having 5 or more data-bearing nodes.
This architecture provides the highest resiliency. There are no interruptions during Atlas operations (like an automated upgrade), and your application can sustain a full regional failure with no interruption and manual intervention required.
5-Node, 2-Region Architecture
If you have an application that can experience limited downtime or maintenance windows without significant revenue impact, you can create an architecture that provides that level of availability by using 5 nodes in 2 regions. You have 3 electable nodes spread across the 2 regions, and also have 2 read-only nodes in the secondary region. The electable nodes are in the majority region, while the region with fewer electable nodes is the minority region.
This is also an appropriate architecture if you need high availability and low latency in a geography that only has 2 regions.
This is a good option for:
Customers with only 2 approved regions.
Meeting governance compliance about data storage.
Applications where read operations need high uptime, but write operations can experience some outage.
Notes and Considerations
This architecture provides increased protection against data loss, even in full regional outage, because the system remains available in read-only mode in the secondary region if the primary region is lost.
While this architecture is less expensive than the 5-Node, 3-Region solution provided above, the reduced cost comes with some caveats:
If the majority region is lost, the minority region is not a fully-functional cluster; it does not have a primary and can only accept reads but not writes.
To turn it into a functional cluster again, an administrator needs to reconfigure the 2 read-only nodes to electable nodes. However, there is a possibility of data loss when the unavailable members are online again. If your MongoDB process didn't replicate the write operations to the node that becomes the new primary, then the recovered replica set rolls back these writes. To learn more, refer to Reconfigure a Replica Set During a Regional Outage.
Note
If the minority region is lost, no action is required, since the majority region remains a fully functional cluster.
In sharded clusters, if your MongoDB process didn't replicate chunk migrations, the data inconsistency might cause orphaned chunks.
Lower-Cost Variation
For further cost savings, you can design this architecture without the 2 read-only nodes. In addition to the caveats listed above, data size has a significant impact on your decision since the data needs to be synchronized to secondaries whenever adding new nodes to the cluster. For example, 1 TB of data averages 1 hour of recovery and synchronization time.
3-Node, 3-Region Architecture
If you have an application that can experience some downtime, and the cost of deployment is more of a factor than availability or latency, you can create an architecture that is less expensive by using 1 node in each of 3 regions. You have a electable node in each of the regions, which means if the primary node is unavailable, there is latency as another node is elected primary and writes are routed to that region. However, you still have availability if any region is unavailable.
Global Deployments
Global Atlas deployments are the most complex multi-region deployment paradigm, and therefore require very careful planning. In almost all cases, a Multi-Region Deployment Paradigm (or its subset, a Multi-Cloud Deployment Paradigm) can fulfill your needs.
You might consider a global deployment strategy if:
You need a single global connection string.
You need to perform global aggregations across all users.
You need the ability to read/write for all users from everywhere in one logical cluster, while also having regional reads/writes.
Note
The complexity of global deployments results in many opinions on best practices. The Atlas Architecture Center does not currently cover recommendations specific to global deployments. Contact MongoDB's Professional Services team to discuss your specific requirements and to design a Atlas global deployment strategy.
Data Sovereignty and High Availability Considerations
For compliance with data residency laws, data can be partitioned to reside in specific regions, ensuring adherence to local regulations. However, deploying to a single region sacrifices high availability if there is a regional outage.
You can configure a multi-region deployment for both high availability
and data sovereignty. For example, for an application deployed with AWS
that requires data storage in Europe, you can deploy a multi-region deployment
to three regions within the EU (such as eu-west-1, eu-west-2,
and eu-west-3). This ensures data sovereignty since all regions are within
the EU, while offering high availability if there's a regional outage that
affects one of the nodes.
Recommendations for Multi-Region Deployments
To find recommendations for your Atlas cloud deployments, refer to the following resources:
Operational Efficiency
Security
Reliability
Performance
Cost Optimization