This section of the Google Cloud deployment archetypes guide describes the multi-regional deployment archetype.
In a cloud architecture that uses the multi-regional deployment archetype, the application runs in two or more Google Cloud regions. Application data is replicated across all the regions in the architecture. To ensure fast and synchronous replication of data, the regions are typically within a continent.
The following diagram shows the cloud topology for an application that runs in two Google Cloud regions:
The preceding diagram shows two isolated multi-tier application stacks that run independently in two Google Cloud regions. In each region, the application runs in three zones. The databases in the two regions are replicated. If the workload has a low recovery point objective (RPO) or if it requires strong cross-region consistency of data, then the database replication needs to be synchronous. Otherwise, the databases can be replicated asynchronously. User requests are routed to regional load balancers by using a DNS routing policy. If an outage occurs in any one of the two regions, DNS routes user requests to the load balancer in the other region.
Use cases
The following sections provide examples of use cases for which the multi-regional deployment archetype is an appropriate choice.
High availability for geographically dispersed users
We recommend a multi-regional deployment for applications that are business-critical and where high availability and robustness against region outages are essential. If a region becomes unavailable for any reason (even a large-scale disruption caused by a natural disaster), users of the application don't experience any downtime. Traffic is routed to the application in the other available regions. If data is replicated synchronously, the recovery time objective (RTO) is near zero.
Low latency for application users
If your users are within a specific geographical area, such as a continent, you can use a multi-regional deployment to achieve an optimal balance between availability and performance. When one of the regions has an outage, the global load balancer sends requests that originate in that region to another region. Users don't perceive significant performance impact because the regions are within a geographical area.
Compliance with data residency and sovereignty requirements
The multi-regional deployment archetype can help you meet regulatory requirements for data residency and operational sovereignty. For example, a country in Europe might require that all user data be stored and accessed in data centers that are located physically within the country. You can deploy the application to Google Cloud regions in Europe and use DNS with a geofenced routing policy to route traffic to the appropriate region.
Design considerations
When you provision and manage redundant resources across locations, the volume of cross-location network traffic can be high. You also store and replicate data across multiple regions. When you build an architecture that uses the multi-regional deployment archetype, consider the potentially higher cost of cloud resources and network traffic, and the complexity of operating the deployment. For business-critical applications, the availability advantage of a multi-region architecture might outweigh the increased cost and operational complexity.
Reference architecture
For a reference architecture that you can use to design a multi-regional deployment on Compute Engine VMs, see Multi‑regional deployment on Compute Engine.