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.