This section of theGoogle Cloud deployment archetypes guide describes the global deployment archetype.

In an architecture that's based on the global deployment archetype, theapplication runs in multipleGoogle Cloud regions across the globe. You can deploy the application either as a distributedlocation-unaware stack or as multiple regionally isolated stacks. In eithercase, a globalanycast load balancer distributes traffic to the appropriate region. The applicationwrites data to, and reads from, a synchronously replicated database that'savailable in all the regions, likeSpanner with multi-region configuration.Other components of the application stack can also be global, such as the cacheand object store.

The following diagram shows the distributed location-unaware variant of theglobal deployment archetype:

The preceding diagram shows a location-unaware application stack, with frontendand backend instances (typically microservices) that are distributed acrossmultiple zones in three Google Cloud regions. A global anycast loadbalancer distributes incoming traffic to an appropriate frontend instance. Thisdistribution is based on the availability and capacity of the instances andtheir geographical proximity to the source of the traffic. Cross-regioninternal load balancers distribute traffic from the frontend instances toappropriate backend instances based on their availability and capacity. Theapplication uses a database that is synchronously replicated and availableacross regions.

The following diagram shows a variant of the global deployment archetype withregionally isolated application stacks:

The preceding diagram shows regionally isolated application stacks that run inmultiple zones in two Google Cloud regions. This topology is similar tothemulti-regional deployment archetype,but it uses a global anycast load balancer instead of DNS routing. The globalload balancer distributes incoming traffic to a frontend in the regionthat's nearest to the user. Both the application stacks write data to, and readfrom, a database that is synchronously replicated and available across both theregions. If an outage occurs in any one of the two regions, the global loadbalancer sends user requests to a frontend in the other region.

Use cases

The following sections provide examples of use cases for which the globaldeployment archetype is an appropriate choice.

Highly available application for a global audience

We recommend the global deployment archetype for applications that serve usersacross the world and, therefore, need high availability and robustness againstoutages in multiple regions.

Opportunity to optimize cost and simplify operations

With the global deployment archetype, you can use highly available globalresources like a global load balancer and a global database. Compared to amulti-regional deployment, a global deployment can help lower costs and simplifyoperations because you provision and manage fewer resources.

Design considerations

When you build an architecture that's based on the global deployment archetype,consider the following design factors.

Storage, replication, and networking costs

In a globally distributed architecture, the volume of cross-location networktraffic can be high compared to a regional deployment. You might also store andreplicate more data. When you build an architecture that's based on the globaldeployment archetype, consider the potentially higher cost for data storage andnetworking. For business-critical applications, the availability advantage of aglobally distributed architecture might outweigh the higher networking andstorage costs.

Managing changes to global resources

The opportunity to use highly available global resources can help you tooptimize cost and simplify operations. However, to ensure that the globalresources don't become single points of failure (SPOF), you must carefullymanage configuration changes to global resources.

Reference architecture

For a reference architecture that you can use to design a global deployment, seeGlobal deployment with Compute Engine and Spanner.