High availability design patterns in Azure - Step-by-Step Execution

Process Flow - High availability design patterns

Start: User Request

↓

Load Balancer receives request

↓

Check service instance health

↓

Route to

↓

Healthy

↓

Instance

↓

Retry or Failover

↓

Process Request

↓

Send Response

↓

End

User requests go through a load balancer that checks service health and routes to healthy instances, retrying or failing over if needed to keep services available.

Execution Sample

Azure

1. User sends request
2. Load balancer checks instance health
3. Routes to healthy instance
4. Instance processes request
5. Response sent back

This flow shows how a request is handled to ensure high availability by routing only to healthy service instances.

Process Table

Step	Action	Instance Health Check	Routing Decision	Result
1	User sends request	N/A	N/A	Request received by load balancer
2	Load balancer checks instance A	Healthy	Route to instance A	Request sent to instance A
3	Instance A processes request	N/A	N/A	Request processed successfully
4	Response sent back to user	N/A	N/A	User receives response
5	Next request arrives	Instance A unhealthy	Route to instance B	Request sent to instance B
6	Instance B processes request	N/A	N/A	Request processed successfully
7	Response sent back to user	N/A	N/A	User receives response
8	Instance B unhealthy	Failover to instance C	Route to instance C	Request sent to instance C
9	Instance C processes request	N/A	N/A	Request processed successfully
10	Response sent back to user	N/A	N/A	User receives response
11	No healthy instances	All unhealthy	Fail request or queue	Request fails or delayed
12	End	N/A	N/A	High availability maintained by routing or failover

💡 Execution stops when request is successfully processed or no healthy instances remain.

Status Tracker

Variable	Start	After Step 2	After Step 5	After Step 8	Final
Instance A Health	Healthy	Healthy	Unhealthy	Unhealthy	Unhealthy
Instance B Health	Healthy	Healthy	Healthy	Unhealthy	Unhealthy
Instance C Health	Healthy	Healthy	Healthy	Healthy	Healthy
Current Routed Instance	None	Instance A	Instance B	Instance C	None or last healthy
Request Status	Pending	Routed	Routed	Routed	Completed or Failed

Key Moments - 3 Insights

Why does the load balancer route to a different instance after step 5?

Because instance A became unhealthy at step 5, the load balancer detects this and routes the request to instance B to maintain availability, as shown in execution_table row 5.

What happens if all instances are unhealthy?

When all instances are unhealthy, as in step 11, the system cannot route requests successfully, so requests fail or are delayed, ensuring no routing to unhealthy instances, as shown in execution_table row 11.

How does the system ensure the user still gets a response if one instance fails?

The load balancer checks health and routes to another healthy instance automatically, retrying the request, as seen in steps 5 to 10 in the execution_table.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the load balancer first route to instance B?

A Step 2

B Step 5

C Step 8

D Step 11

💡 Hint

Check the Routing Decision column in execution_table rows around step 5.

According to variable_tracker, what is the health status of instance C after step 8?

A Healthy

B Unhealthy

C Unknown

D Pending

💡 Hint

Look at the 'Instance C Health' row and the 'After Step 8' column in variable_tracker.

If instance A remained healthy, how would the routing change in the execution_table?

A Requests would fail at step 11

B Requests would route to instance B first

C Requests would always route to instance A

D Load balancer would route randomly

💡 Hint

Refer to the routing decisions in execution_table when instance A is healthy.

Concept Snapshot

High availability means keeping services running without interruption.
Use load balancers to check instance health.
Route requests only to healthy instances.
If one fails, failover to another.
If none healthy, requests fail or queue.
This pattern keeps apps available to users.

Full Transcript

High availability design patterns in Azure use load balancers to manage user requests. When a user sends a request, the load balancer checks which service instances are healthy. It routes the request only to healthy instances. If an instance becomes unhealthy, the load balancer redirects requests to other healthy instances to keep the service running. If all instances are unhealthy, requests may fail or be delayed. This ensures users get responses reliably by avoiding failed instances and using failover automatically.

Practice

1. Which Azure service is primarily used to distribute incoming traffic across multiple virtual machines to ensure high availability?

easy

A. Azure Functions

B. Azure Blob Storage

C. Azure Load Balancer

D. Azure Cosmos DB

Solution

1. Step 1: Understand the role of Azure Load Balancer

   Azure Load Balancer distributes incoming network traffic across multiple VMs to prevent any single VM from becoming a bottleneck.

2. Step 2: Compare with other services

   Azure Blob Storage stores data, Azure Functions run code, and Cosmos DB is a database service; none distribute traffic.

3. Final Answer:

   Azure Load Balancer -> Option C

4. Quick Check:

   Traffic distribution = Azure Load Balancer [OK]

Hint: Load Balancer spreads traffic to VMs for uptime [OK]

Common Mistakes:

• Confusing storage or compute services with traffic distribution
• Choosing Azure Functions for load balancing
• Selecting database services for availability patterns

2. Which of the following is the correct syntax to create an Azure VM Scale Set using Azure CLI for high availability?

easy

A. az vm create --name MyScaleSet --resource-group MyResourceGroup --image UbuntuLTS --instance-count 3

B. az vm create --name MyScaleSet --resource-group MyResourceGroup --image UbuntuLTS --count 3

C. az vmss deploy --name MyScaleSet --group MyResourceGroup --image UbuntuLTS --instances 3

D. az vmss create --name MyScaleSet --resource-group MyResourceGroup --image UbuntuLTS --instance-count 3

Solution

1. Step 1: Identify the correct Azure CLI command for VM Scale Set creation

   The command to create a VM Scale Set is az vmss create, not az vm create.

2. Step 2: Check the parameters

   Parameters like --name, --resource-group, --image, and --instance-count are correctly used in az vmss create --name MyScaleSet --resource-group MyResourceGroup --image UbuntuLTS --instance-count 3.

3. Final Answer:

   az vmss create --name MyScaleSet --resource-group MyResourceGroup --image UbuntuLTS --instance-count 3 -> Option D

4. Quick Check:

   VM Scale Set creation uses az vmss create [OK]

Hint: Use 'az vmss create' for VM Scale Sets [OK]

Common Mistakes:

• Using 'az vm create' instead of 'az vmss create'
• Incorrect parameter names like --count instead of --instance-count
• Mixing resource group parameter names

3. Consider this Azure Load Balancer configuration snippet:

frontendIPConfiguration:
  name: LoadBalancerFrontEnd
  publicIPAddress:
    id: /subscriptions/xxx/resourceGroups/rg/providers/Microsoft.Network/publicIPAddresses/myPublicIP
backendAddressPools:
  - name: BackendPool
loadBalancingRules:
  - name: HTTPRule
    frontendIPConfiguration: LoadBalancerFrontEnd
    backendAddressPool: BackendPool
    protocol: Tcp
    frontendPort: 80
    backendPort: 80
    enableFloatingIP: false
    idleTimeoutInMinutes: 4
    loadDistribution: Default

What will happen if one VM in the backend pool becomes unhealthy?

medium

A. Traffic will automatically stop going to the unhealthy VM

B. Traffic will continue to be sent to the unhealthy VM

C. Load Balancer will restart the unhealthy VM

D. Load Balancer will redirect traffic to a different port

Solution

1. Step 1: Understand Azure Load Balancer health probe behavior

   Azure Load Balancer requires health probes configured to detect unhealthy VMs and stop sending traffic to them. This snippet does not show health probes configured, but in practice, health probes are necessary for proper load balancing.

2. Step 2: Analyze the effect of missing health probes

   Without health probes, the Load Balancer cannot detect unhealthy VMs, so it continues sending traffic to all VMs in the backend pool. However, best practice is to configure health probes to avoid this.

3. Final Answer:

   Traffic will automatically stop going to the unhealthy VM -> Option A

4. Quick Check:

   Health probes detect unhealthy VMs and stop traffic [OK]

Hint: Configure health probes to avoid sending traffic to bad VMs [OK]

Common Mistakes:

• Assuming Load Balancer auto-detects unhealthy VMs without probes
• Thinking Load Balancer restarts VMs
• Confusing port redirection with load balancing

4. You have configured an Active-Passive high availability setup using Azure Traffic Manager. However, during failover, users experience downtime. What is the most likely cause?

medium

A. Traffic Manager is set to Performance routing with multiple active endpoints

B. Traffic Manager is set to Priority routing but health probes are misconfigured

C. Azure Load Balancer is not configured with a public IP

D. VM Scale Set has only one instance

Solution

1. Step 1: Understand Active-Passive with Traffic Manager Priority routing

   Priority routing sends traffic to the primary endpoint unless it is unhealthy, then fails over to secondary.

2. Step 2: Identify impact of misconfigured health probes

   If health probes are misconfigured, Traffic Manager cannot detect endpoint health and will not failover properly, causing downtime.

3. Final Answer:

   Traffic Manager is set to Priority routing but health probes are misconfigured -> Option B

4. Quick Check:

   Priority routing + bad probes = failover fails [OK]

Hint: Check health probes when failover fails in Priority routing [OK]

Common Mistakes:

• Confusing routing methods in Traffic Manager
• Blaming Load Balancer or VM Scale Set for Traffic Manager failover
• Ignoring health probe configuration

5. You want to design a geo-redundant high availability solution for a web app in Azure that must remain available even if an entire Azure region fails. Which combination of Azure services and design patterns best achieves this?

hard

A. Deploy the app in two regions with Azure Traffic Manager using Performance routing and Azure SQL Geo-Replication

B. Deploy the app in one region with Azure Load Balancer and VM Scale Sets, and use Azure Backup for disaster recovery

C. Deploy the app in two regions with Azure Traffic Manager using Priority routing and VM Scale Sets in each region

D. Deploy the app in one region with Azure Application Gateway and use Azure Blob Storage for static content

Solution

1. Step 1: Understand geo-redundancy requirements

   To survive a full region failure, the app must be deployed in multiple regions with traffic routed between them.

2. Step 2: Evaluate options for traffic routing and data replication

   Performance routing in Traffic Manager directs users to the closest healthy region. Azure SQL Geo-Replication ensures database availability across regions.

3. Step 3: Compare with other options

   Priority routing is for Active-Passive, not best for geo-load balancing. Single region deployments cannot survive region failure. Application Gateway is regional and does not provide geo-failover.

4. Final Answer:

   Deploy the app in two regions with Azure Traffic Manager using Performance routing and Azure SQL Geo-Replication -> Option A

5. Quick Check:

   Geo-redundancy needs multi-region + performance routing + geo-replication [OK]

Hint: Use multi-region + Traffic Manager Performance + Geo-Replication [OK]

Common Mistakes:

• Choosing Priority routing for geo-load balancing
• Relying on single region with backup for high availability
• Confusing Application Gateway with global traffic routing