Multi-region architecture patterns in GCP - Step-by-Step Execution

Process Flow - Multi-region architecture patterns

User Request

↓

DNS Route to Region

↓

Region 1: Primary

↓

Region 2: Secondary

↓

Data Replication & Sync

↓

Failover Trigger?

No→Serve from Primary

Yes↓

Serve from Secondary

User requests are routed by DNS to a primary region. Data replicates between regions. If primary fails, traffic fails over to secondary region.

Execution Sample

GCP

1. User sends request to app.example.com
2. DNS resolves to Region 1 IP
3. App in Region 1 serves request
4. Data replicates asynchronously to Region 2
5. If Region 1 fails, DNS switches to Region 2

This sequence shows how a multi-region app routes user requests and handles failover.

Process Table

Step	Action	Region 1 State	Region 2 State	Result
1	User requests app.example.com	Running	Running	DNS resolves to Region 1 IP
2	Request sent to Region 1	Serving request	Idle	User served from Region 1
3	Data changes in Region 1	Data updated	Data stale	Replication starts
4	Data replicates to Region 2	Data updated	Data updated	Data in sync
5	Region 1 fails	Down	Running	Failover triggered
6	DNS updates to Region 2 IP	Down	Serving request	User served from Region 2
7	Region 1 recovers	Running	Running	Normal operation resumes

💡 Execution stops after failover and recovery steps complete.

Status Tracker

Variable	Start	After Step 3	After Step 4	After Step 5	After Step 6	Final
Region 1 State	Running	Running	Running	Down	Down	Running
Region 2 State	Running	Data stale	Data updated	Running	Serving request	Running
DNS Route	Region 1 IP	Region 1 IP	Region 1 IP	Region 1 IP	Region 2 IP	Region 1 IP

Key Moments - 3 Insights

Why does the DNS route stay pointing to Region 1 even after data replication starts?

Because replication is asynchronous, DNS continues routing to Region 1 until a failover event occurs, as shown in steps 3 and 4 of the execution_table.

What triggers the failover to Region 2?

Failover triggers when Region 1 state changes to Down (step 5), causing DNS to update to Region 2 IP (step 6) to serve user requests.

Why does Region 2 serve requests only after DNS updates?

Because user requests are routed by DNS, Region 2 only receives traffic after DNS changes, as shown in step 6.

Visual Quiz - 3 Questions

Look at the execution_table, what is the state of Region 2 at step 4?

A Idle

B Serving request

C Data updated

D Down

💡 Hint

Check the 'Region 2 State' column at step 4 in the execution_table.

At which step does DNS route change to Region 2 IP?

A Step 4

B Step 6

C Step 5

D Step 3

💡 Hint

Look at the 'DNS Route' variable in variable_tracker after step 6.

If Region 1 never fails, what would happen to the DNS route?

A It would remain pointing to Region 1 IP

B It would switch to Region 2 IP anyway

C It would alternate between Region 1 and 2 IP

D It would point to both regions simultaneously

💡 Hint

Refer to the failover trigger explanation in key_moments and DNS Route values in variable_tracker.

Concept Snapshot

Multi-region architecture routes user requests via DNS to a primary region.
Data replicates asynchronously to secondary regions.
If primary fails, DNS updates to route traffic to secondary.
This ensures high availability and disaster recovery.
Failover depends on health checks and DNS updates.

Full Transcript

Multi-region architecture patterns involve routing user requests to a primary region using DNS. Data is asynchronously replicated to secondary regions to keep them updated. When the primary region fails, a failover process triggers DNS to update and route traffic to a healthy secondary region. This pattern improves availability and disaster recovery by distributing workloads across multiple geographic locations. The execution steps show user requests served from primary until failure, then switching to secondary after DNS updates. Variables track region states and DNS routing changes over time.

Practice

1. What is the main benefit of using a multi-region architecture in cloud services?

easy

A. Improved availability and reduced latency for users

B. Lower cost by using only one data center

C. Simpler setup with fewer resources

D. Avoiding the use of load balancers

Solution

1. Step 1: Understand multi-region purpose

   Multi-region architecture places resources in different geographic locations to improve service reliability and speed.

2. Step 2: Identify benefits

   This setup reduces downtime and latency by serving users from the closest healthy region.

3. Final Answer:

   Improved availability and reduced latency for users -> Option A

4. Quick Check:

   Multi-region = availability + latency improvement [OK]

Hint: Multi-region means better uptime and faster access [OK]

Common Mistakes:

• Thinking multi-region reduces cost by using fewer resources
• Assuming it simplifies setup instead of adding complexity
• Believing load balancers are not needed

2. Which GCP service is commonly used as a global load balancer to route traffic to the nearest region?

easy

A. Cloud Functions

B. Cloud CDN

C. Cloud Storage

D. Cloud Load Balancing

Solution

1. Step 1: Identify global load balancer service

   Cloud Load Balancing in GCP can distribute traffic globally and route users to the closest healthy backend.

2. Step 2: Exclude other services

   Cloud Storage is for files, Cloud CDN caches content, Cloud Functions run code, none route traffic globally.

3. Final Answer:

   Cloud Load Balancing -> Option D

4. Quick Check:

   Global traffic routing = Cloud Load Balancing [OK]

Hint: Global traffic routing uses Cloud Load Balancing [OK]

Common Mistakes:

• Confusing Cloud CDN with load balancing
• Thinking Cloud Storage handles traffic routing
• Assuming Cloud Functions manage global traffic

3. Consider this setup: A multi-region app uses Cloud Load Balancing with backends in us-central1 and europe-west1. If us-central1 backend fails health checks, where will traffic go?

medium

A. Traffic stops until us-central1 recovers

B. Traffic routes to europe-west1 backend

C. Traffic routes randomly to any backend

D. Traffic routes to a single zone in us-central1

Solution

1. Step 1: Understand health checks in load balancing

   Cloud Load Balancing monitors backend health and stops sending traffic to unhealthy backends.

2. Step 2: Determine traffic routing on failure

   If us-central1 fails, traffic automatically shifts to healthy backends like europe-west1.

3. Final Answer:

   Traffic routes to europe-west1 backend -> Option B

4. Quick Check:

   Unhealthy backend traffic rerouted to healthy backend [OK]

Hint: Traffic goes only to healthy backends [OK]

Common Mistakes:

• Assuming traffic stops on failure
• Thinking traffic routes randomly
• Believing traffic stays in the same region despite failure

4. You deployed a multi-region app but users in Asia experience high latency. Which mistake likely caused this?

medium

A. Deploying backends in multiple continents

B. Enabling global load balancing

C. Using a single region in the US only

D. Configuring health checks properly

Solution

1. Step 1: Analyze latency cause

   High latency in Asia means traffic is routed far away, likely because no nearby region exists.

2. Step 2: Identify deployment mistake

   Using only a US region means no local backend for Asia users, causing delays.

3. Final Answer:

   Using a single region in the US only -> Option C

4. Quick Check:

   Single distant region causes high latency [OK]

Hint: No local region means high latency for distant users [OK]

Common Mistakes:

• Thinking global load balancing causes latency
• Assuming multiple continents always cause latency
• Ignoring health check configuration impact

5. You want to design a multi-region architecture for a global app that must stay online even if an entire region fails. Which setup best meets this requirement?

hard

A. Deploy app in multiple regions with global load balancing and health checks

B. Deploy app in one region with multiple zones and use regional load balancing

C. Deploy app in one zone only and use Cloud CDN

D. Deploy app in multiple zones within the same region without load balancing

Solution

1. Step 1: Understand high availability needs

   To stay online if a whole region fails, app must run in multiple regions, not just zones.

2. Step 2: Choose architecture with global load balancing

   Global load balancing routes traffic to healthy regions automatically, ensuring uptime.

3. Step 3: Exclude less resilient options

   Single region or zone setups fail if that region/zone goes down; Cloud CDN alone doesn't provide failover.

4. Final Answer:

   Deploy app in multiple regions with global load balancing and health checks -> Option A

5. Quick Check:

   Multi-region + global load balancing = high availability [OK]

Hint: Multi-region plus global load balancing ensures uptime [OK]

Common Mistakes:

• Relying on zones instead of regions for failover
• Using only regional load balancing for global failover
• Thinking Cloud CDN replaces multi-region deployment