High availability design patterns in Azure - Deep Dive

Overview - High availability design patterns

What is it?

High availability design patterns are ways to build computer systems that keep working even if parts fail. They use multiple copies of important parts and smart ways to switch between them quickly. This helps avoid downtime, so users can always access services. These patterns are common in cloud systems like Azure to ensure reliability.

Why it matters

Without high availability, websites and apps can stop working when something breaks, causing frustration and loss of trust. Businesses can lose money and customers if their services are down. High availability design patterns solve this by making systems resilient, so they keep running smoothly even during failures.

Where it fits

Before learning this, you should understand basic cloud concepts like virtual machines, networking, and storage. After this, you can explore disaster recovery, scaling strategies, and cost optimization to build even stronger cloud solutions.

Mental Model

Core Idea

High availability design patterns create backup paths and copies so systems keep running without interruption when parts fail.

Think of it like...

It's like having multiple bridges over a river; if one bridge is closed, cars can still cross using another bridge without stopping traffic.

┌───────────────┐      ┌───────────────┐
│ Primary Node  │─────▶│ User Requests │
└──────┬────────┘      └───────────────┘
       │
       │ Failover
       ▼
┌───────────────┐
│ Secondary Node│
└───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding system failures

Concept: Systems can fail in many ways, and knowing these helps design for availability.

Failures can be hardware crashes, software bugs, network issues, or power outages. Recognizing these helps us plan backups and quick recovery methods.

Result

You know what can go wrong and why systems might stop working.

Understanding failure types is key to choosing the right high availability pattern.

2

Foundation

Basics of redundancy

Concept: Redundancy means having extra copies or parts ready to take over if one fails.

For example, having two servers running the same service means if one stops, the other can continue serving users without interruption.

Result

You grasp why having backups is essential for continuous service.

Knowing redundancy prevents single points of failure that cause downtime.

3

Intermediate

Active-passive failover pattern

🤔Before reading on: do you think the passive node handles requests before failover or only after? Commit to your answer.

Concept: One node handles all traffic while another waits silently to take over if the first fails.

In this pattern, the active node processes requests. The passive node monitors the active one and takes over instantly if it detects failure, ensuring minimal downtime.

Result

Systems switch smoothly to backup nodes when problems occur.

Understanding this pattern helps design simple, reliable failover systems.

4

Intermediate

Active-active load balancing pattern

🤔Before reading on: do you think active-active means both nodes share traffic or only one at a time? Commit to your answer.

Concept: Multiple nodes handle traffic simultaneously, sharing the load and providing backup for each other.

Here, all nodes are active and serve users together. If one node fails, others continue without interruption, balancing traffic dynamically.

Result

Systems achieve higher capacity and resilience by sharing work.

Knowing this pattern improves performance and availability together.

5

Intermediate

Geographic redundancy pattern

Concept: Systems are duplicated in different physical locations to survive regional failures.

By placing copies of services in different data centers or regions, if one location has a disaster, others keep the service running.

Result

Services remain available even during large-scale outages.

Understanding geographic redundancy protects against wide-area failures.

6

Advanced

Designing for automatic failover

🤔Before reading on: do you think failover should be manual or automatic for best availability? Commit to your answer.

Concept: Automatic failover detects failures and switches traffic without human help.

Using health checks and monitoring, systems detect problems and redirect users instantly to healthy nodes, reducing downtime to seconds.

Result

Users experience seamless service even during failures.

Knowing automatic failover reduces human error and speeds recovery.

7

Expert

Balancing consistency and availability

🤔Before reading on: do you think systems can be fully consistent and always available during failures? Commit to your answer.

Concept: Tradeoffs exist between data consistency and availability during failures, known as the CAP theorem.

Systems must choose between always showing the latest data (consistency) or always responding quickly (availability). High availability patterns often favor availability, using techniques like eventual consistency.

Result

You understand why some systems accept slight delays in data updates to stay online.

Understanding this tradeoff helps design systems that meet real-world needs without unrealistic guarantees.

Under the Hood

High availability patterns use multiple copies of services and data, health monitoring, and routing logic. When a failure is detected, traffic is redirected to healthy nodes automatically or manually. Load balancers distribute requests, and data replication keeps copies synchronized. These components work together to mask failures from users.

Why designed this way?

Systems were designed this way to avoid single points of failure and reduce downtime. Early systems failed often and caused big disruptions. By adding redundancy and automatic switching, availability improved dramatically. Alternatives like manual recovery were too slow and error-prone.

┌───────────────┐       ┌───────────────┐
│   User        │──────▶│ Load Balancer │
└──────┬────────┘       └──────┬────────┘
       │                       │
       │                       │
       ▼                       ▼
┌───────────────┐       ┌───────────────┐
│ Node 1 (Active)│       │ Node 2 (Backup)│
└───────────────┘       └───────────────┘
       ▲                       ▲
       │                       │
       └───── Health Checks ───┘

Myth Busters - 4 Common Misconceptions

Quick: does having multiple servers always guarantee zero downtime? Commit to yes or no.

Common Belief: If you have multiple servers, your system will never go down.

Reality: Multiple servers help, but if they are not properly monitored or configured, failures can still cause downtime.

Why it matters: Assuming redundancy alone is enough can lead to unpreparedness and unexpected outages.

Quick: do you think active-passive means both nodes share traffic equally? Commit to yes or no.

Common Belief: Active-passive means both nodes handle traffic at the same time.

Reality: In active-passive, only the active node handles traffic; the passive node waits silently to take over.

Why it matters: Misunderstanding this can cause wrong load balancing setups and wasted resources.

Quick: do you think automatic failover always happens instantly without any delay? Commit to yes or no.

Common Belief: Automatic failover switches immediately with no downtime.

Reality: Failover takes some time for detection and switching, so brief interruptions can occur.

Why it matters: Expecting zero delay can lead to unrealistic SLAs and poor user experience planning.

Quick: do you think systems can be fully consistent and fully available during network partitions? Commit to yes or no.

Common Belief: Systems can always be both fully consistent and fully available, no matter what.

Reality: Due to the CAP theorem, during network splits, systems must choose between consistency and availability.

Why it matters: Ignoring this leads to design mistakes causing data loss or downtime.

Expert Zone

1

Failover timing is a balance: too fast causes false alarms, too slow causes downtime.

2

Data replication lag can cause temporary inconsistencies that must be managed carefully.

3

Load balancers themselves can become single points of failure if not designed redundantly.

When NOT to use

High availability patterns are not always needed for non-critical or low-traffic systems where cost matters more. In such cases, simpler backup and recovery or scheduled maintenance windows may suffice.

Production Patterns

In Azure, production systems use paired regions for geographic redundancy, Azure Load Balancer or Traffic Manager for active-active patterns, and Azure SQL with automatic failover groups. Monitoring with Azure Monitor triggers automatic failover and alerts.

Connections

Disaster Recovery

Builds-on

High availability keeps systems running during small failures, while disaster recovery plans handle large-scale disasters and data restoration.

CAP Theorem

Explains tradeoffs

Understanding CAP helps grasp why high availability systems sometimes accept eventual consistency to stay online.

Electrical Grid Design

Shares design principles

Both use redundancy and automatic switching to keep power or services flowing despite failures.

Common Pitfalls

#1 Ignoring health checks causes failover to not trigger.

Wrong approach:

Configure two servers but do not set up monitoring or health probes.

Correct approach:

Set up health probes that regularly check server status and trigger failover if unhealthy.

Root cause:

Misunderstanding that redundancy alone is not enough without monitoring.

#2 Using a single load balancer without redundancy creates a single point of failure.

Wrong approach:

Deploy one load balancer instance without backup.

Correct approach:

Deploy multiple load balancers with failover or use managed services with built-in redundancy.

Root cause:

Overlooking that load balancers themselves can fail and cause downtime.

#3 Failing to test failover leads to surprises during real outages.

Wrong approach:

Set up failover but never simulate failures or drills.

Correct approach:

Regularly test failover processes to ensure they work smoothly.

Root cause:

Assuming configurations work without validation.

Key Takeaways

High availability design patterns ensure systems keep working during failures by using redundancy and failover.

Active-passive and active-active are common patterns balancing simplicity and performance.

Automatic failover reduces downtime but requires careful monitoring and testing.

Tradeoffs between consistency and availability must be understood to design realistic systems.

Proper configuration, monitoring, and testing are essential to avoid hidden single points of failure.

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