High Availability Patterns: Active-Active vs. Active-Passive

High availability (HA) ensures systems stay online with minimal downtime. Two common approaches are Active-Active and Active-Passive architectures. Here's what you need to know:

• Active-Active: Multiple nodes handle traffic simultaneously. If one fails, others take over instantly. It offers near-zero downtime but is more expensive and complex.
• Active-Passive: A primary node handles traffic while a standby waits in reserve. Failover takes longer (minutes), but it's simpler and more cost-effective.

Key Differences:

• Uptime: Active-Active supports 99.99% (52 mins downtime/year); Active-Passive supports 99.9% (8.77 hrs downtime/year).
• Cost: Active-Active costs 2–3x a single-region setup; Active-Passive costs 1.2–1.5x.
• Complexity: Active-Active requires advanced conflict resolution; Active-Passive is easier to manage.

When to Choose:

• Use Active-Active for critical systems needing continuous availability (e.g., payment platforms).
• Use Active-Passive for systems where brief downtime is acceptable and budgets are tighter (e.g., back-office tools).

Quick Comparison:

Choosing the right architecture depends on your recovery needs, budget, and tolerance for downtime.

::: @figure {Active-Active vs Active-Passive: High Availability Architecture Comparison} :::

Key Concepts in High Availability

Core Reliability Metrics: RTO and RPO

When designing for high availability, two critical metrics come into play: RTO (Recovery Time Objective) and RPO (Recovery Point Objective).

• RTO refers to the maximum downtime a system can tolerate after a failure.
• RPO measures the maximum duration of data loss acceptable in the event of an issue.

The specific targets for these metrics depend heavily on the workload. For example:

• A SaaS platform might allow for an RTO of 10 minutes and an RPO of 5 minutes.
• During major events like Black Friday, an e-commerce site might require an RTO of under 2 minutes.
• Financial services handling real-time payments could demand near-zero downtime and data loss.

The system architecture must align with these targets, as shown below:

Once these metrics are defined, the next step is to understand how failover mechanisms support these goals.

Failover Mechanisms and Load Balancing

Failover ensures that when a system component fails, traffic is quickly redirected to a healthy alternative. The effectiveness of this process depends on the design.

• Active-Active setups: A load balancer distributes traffic across all active nodes using methods like round-robin, least connections, or weighted routing [4]. If a node fails, traffic is rerouted almost instantly.
• Active-Passive setups: Here, the load balancer activates the standby node only after the primary node fails, leading to slightly longer recovery times.

It’s important to differentiate between control-plane and data-plane failover:

• Control-plane failover involves launching new instances or updating DNS records. However, this can be unreliable during outages. For example, the AWS us-east-1 outage in December 2021 lasted seven hours and disrupted these operations [2].
• Data-plane failover relies on pre-configured routing, which operates independently of the cloud provider’s real-time infrastructure changes. This makes it more resilient.

Failover that depends on control-plane operations (launching EC2, changing DNS records) is itself vulnerable to the outage. - The HLD Handbook [2]

DNS-based failover is commonly used but can face delays of 1–5 minutes due to DNS resolver caching. On the other hand, anycast-based routing - offered by services like AWS Global Accelerator and Cloudflare - enables recovery in under a second [2][7]. Setting DNS TTLs to 30–60 seconds is a practical way to reduce delays caused by cached IP addresses [2][7].

These mechanisms, combined with cloud services, form the backbone of high availability strategies.

Cloud Building Blocks for HA

Cloud providers offer a range of tools that simplify the creation of high availability systems, supporting both Active-Active and Active-Passive designs.

• Traffic Routing: Services like AWS Route 53 and Azure Traffic Manager provide DNS-based failover and latency-based routing. For faster recovery, AWS Global Accelerator and Cloudflare’s anycast routing are excellent options.
• Database Layer: Active-Active systems often use multi-master or globally distributed databases such as DynamoDB Global Tables, Google Spanner, CockroachDB, or Azure Cosmos DB, which handle writes from multiple regions [2][9]. Active-Passive designs typically rely on asynchronous replication, like Aurora Global Database or RDS Cross-Region Read Replicas [2][9].
• Compute Orchestration: Tools like AWS Auto Scaling Groups, Azure VM Scale Sets, and Kubernetes (via EKS or AKS) ensure application stacks are consistently available across regions [9][10].
• Storage Replication: Cross-region replication services, such as S3 Cross-Region Replication or Azure Blob Storage with RA-GRS, maintain access to critical data even during regional outages.

One thing to keep in mind: transferring data between AWS regions costs approximately 1.6p per GB [2], which could influence costs in Active-Active setups.

Active-Active Architecture: Design and Use Cases

What is Active-Active?

In an Active-Active setup, every node in the cluster is fully operational and handles traffic at the same time. This configuration relies on a load balancer to distribute traffic across nodes, ensuring that if one node fails, traffic is redirected almost instantly, achieving near-zero recovery time objectives (RTO) [1].

High availability is all about eliminating single points of failure, meaning that, should a problem occur with a particular node, another node is available to take on the work. - Paul Scrutton, Software System Engineer, SIOS [1]

Key Characteristics and Benefits

One of the standout advantages of an Active-Active architecture is that it maximises resource usage. Unlike Active-Passive setups - where standby nodes remain idle and still incur costs - every server in an Active-Active cluster actively processes traffic. This model also supports horizontal scaling, allowing organisations to add nodes dynamically during traffic surges using cloud auto-scaling tools.

That said, this approach comes with its own challenges, particularly around maintaining data consistency. When multiple nodes can handle simultaneous writes, organisations must adopt conflict resolution mechanisms to ensure data integrity. Common strategies include:

Active-active is not just an architecture. It is a rigorous operational practice. Without regular drills, the failover path rots. - HLD Handbook [2]

These features make Active-Active an appealing choice for applications where downtime is not an option.

When to Use Active-Active

Active-Active architectures are ideal for scenarios where uptime is critical. This setup is specifically designed for environments demanding continuous availability, often achieving 99.99% uptime (commonly referred to as four nines). To put this into perspective, 99.99% availability translates to only about 52 minutes of downtime annually, compared to over 8 hours for 99.9% availability [12]. Such reliability is essential for services like payment platforms, real-time collaboration tools, and global customer-facing applications.

A prime example of this in action is Netflix's 2013 deployment of an Active-Active architecture across AWS regions (us-east-1 and us-west-2). They used Apache Cassandra for asynchronous multi-region replication and Zuul for edge traffic routing. Netflix engineers demonstrated that 1,000,000 records written in one region could be read in the other within 500ms. This setup allowed Netflix to manage outages by seamlessly redirecting traffic in minutes [2]. This case study highlights how Active-Active designs can meet demanding service levels.

For organisations in the UK, GDPR compliance adds another layer of complexity. A geographically partitioned or cell-based Active-Active architecture can ensure that UK and EU user data remains within the European Economic Area (EEA), while still delivering global availability. This makes it particularly suitable for industries like fintech and healthtech, where personal data must be handled across borders [8].

When the hourly cost of downtime exceeds the monthly cost of running a second active region, the business case for active-active becomes straightforward. - SystemsArchitect Team [3]

For teams still building their expertise in distributed systems, it may be wise to begin with an Active-Passive setup and transition to Active-Active as operational experience grows.

Active-Passive Architecture: Design and Use Cases

What is Active-Passive?

In an Active-Passive setup, one node, known as the primary, takes on all production traffic, while the standby node(s) remain idle until the primary encounters an issue. A continuous heartbeat monitors the primary's health. If this signal is lost or the primary's performance drops, the system detects the fault and initiates a failover, redirecting traffic to the standby node [4].

Data replication can be synchronous or asynchronous, ensuring the standby node stays updated and reducing the risk of data loss [4][6]. Once the standby takes over, it becomes the new primary until the original node is repaired and reinstated.

The secondary region is not actively serving users but is prepared to take over if the primary fails. It's a design that minimizes operational complexity while still protecting against regional outages. - Suleyman Cabir Ataman, PhD [9]

Key Characteristics and Benefits

The standout feature of Active-Passive architecture is its straightforwardness. With only one node writing data at any time, there are no concerns about resolving write conflicts, which often complicate Active-Active systems [7][2].

Active-passive is simpler from a data consistency standpoint - there's one writer, so there are no conflicts. - Zak Hassan, Staff SRE [7]

From a cost perspective, Active-Passive is economical, typically costing about 1.2 to 1.3 times more than a single-region setup. Unlike Active-Active configurations, where all nodes are active, the passive nodes in this setup consume fewer resources, leading to savings on power, cooling, and hardware wear [7][1].

However, there are trade-offs. The standby node remains idle during normal operations, meaning you're paying for capacity that isn't actively used [4][13]. Additionally, Recovery Time Objectives (RTO) can range from 1 to over 10 minutes. This delay is partly due to DNS-based failover, which can take 1 to 5 minutes even with low TTL settings [2][7]. The Recovery Point Objective (RPO) depends on the replication lag at the time of failure, making it crucial to monitor this metric closely [7].

One operational risk is the potential failure of a passive node that hasn’t been tested regularly. To mitigate this, teams should conduct routine failover drills to ensure reliability [2].

With its simplicity and cost efficiency, Active-Passive is a great fit for scenarios where minimal downtime is acceptable.

When to Use Active-Passive

Active-Passive is ideal for environments where some downtime is tolerable and budgets are a concern. It’s especially suitable for organisations aiming for three nines (99.9%) uptime, which translates to about 8.77 hours of downtime annually, and where the cost of Active-Active solutions is hard to justify [1][12].

This architecture works well for:

• Back-office systems and internal tools: Moderate RTO requirements and low write complexity make it a suitable choice [1].
• Relational databases: Systems like PostgreSQL benefit from the single-writer model, which avoids conflicts [7].
• Cost-sensitive infrastructure: Small and medium enterprises (SMEs) can save money with Active-Passive, as it costs 1.2x–1.3x compared to 2x–3x for Active-Active [7].
• Legacy applications: These often require simpler management without the need for conflict resolution [4].

For UK-based businesses, especially those handling financial data or operating under UK GDPR regulations, the single-writer model ensures a clear primary data location with a synchronised backup for disaster recovery [2].

For teams new to high availability, Active-Passive is often the best starting point. It’s easier to implement, troubleshoot, and still provides solid protection against single points of failure [4].

Comparing Active-Active and Active-Passive

Comparison Table

Choosing the right architecture depends on your system's specific needs. Below is a direct comparison of Active-Active and Active-Passive setups based on key metrics:

Active-Active is ideal when you need near-zero downtime and have the operational expertise to manage its complexity. On the other hand, Active-Passive works well if you’re looking for a cost-conscious solution and can tolerate brief outages.

As RTO and RPO shrink toward zero, infrastructure cost multiplies: backup-and-restore is cheap with hours of recovery; active-active is expensive with near-zero recovery. - HLD Handbook [2]

Factors to Consider for UK Businesses

Beyond the technical aspects, UK organisations must account for practical factors like latency, budget, and compliance. These considerations often shape the decision between Active-Active and Active-Passive architectures.

Latency is critical. Hosting UK services in a US-based region introduces at least 80 ms of round-trip latency due to physical distance [2]. For applications where speed is crucial - such as e-commerce, financial trading, or real-time dashboards - this delay can be a dealbreaker. Incorporating a UK or European region into an Active-Active setup solves this issue, ensuring faster response times for local users.

Budget is another key factor. For example, a business spending £20,000 monthly on cloud infrastructure would face an additional £5,000 for a warm standby Active-Passive setup, compared to roughly £18,000 extra for a full Active-Active deployment [3]. For SMEs, this cost difference can heavily influence the decision, especially when balancing resilience with affordability.

Data residency is also a pressing concern under UK GDPR. Active-Passive’s single-writer model makes it easier to designate a primary UK-based data location, with a synchronised replica for disaster recovery. This setup provides a clear and auditable approach to compliance without unnecessary architectural complexity, making it a practical choice for many businesses.

How Hokstad Consulting Can Help

Understanding the trade-offs between these architectures is just the first step. Tailoring a solution to meet uptime, budget, and compliance needs is where expertise comes in. Over-engineering can lead to inflated costs, while under-engineering risks outages that could harm your business.

Hokstad Consulting specialises in assessing availability requirements and designing high-availability architectures that align with your needs - without overspending. Their expertise in cloud cost engineering has helped clients reduce infrastructure spending by 30–50%, and their cloud migration strategies ensure smooth, downtime-free transitions. Whether you’re upgrading to Active-Passive or exploring Active-Active for demanding workloads, they provide independent assessments and actionable implementation plans.

Conclusion

Key Takeaways

Aligning your high availability (HA) architecture with your specific recovery time objective (RTO) and business needs is essential. The right choice depends on your operational and recovery demands. For moderate recovery requirements, Active-Passive offers a more economical solution. On the other hand, Active-Active is designed for businesses that cannot afford any downtime.

Here’s a simple rule of thumb: if your business demands an RTO of less than 30 seconds, Active-Active is the way to go. However, if an RTO of up to 10 minutes is acceptable, Active-Passive with a warm standby setup is a practical and efficient choice.

One critical point: a disaster recovery plan that hasn’t been tested is as good as not having one. Running monthly failover drills is non-negotiable.

The engineers who sleep well during regional outages are not the ones who wrote the best incident blog posts. They're the ones who already ran the test six weeks ago. - Zak Hassan, Staff SRE [7]

These insights provide a foundation for making informed decisions tailored to the needs of UK businesses.

Next Steps for UK Organisations

Start by evaluating your current RTO and recovery point objective (RPO). This will help you determine whether your infrastructure is overcomplicated with unnecessary Active-Active configurations or underprepared, leaving you vulnerable to outages.

If you need expert guidance, Hokstad Consulting can assist with an objective assessment. Their expertise in cloud cost engineering has helped clients reduce infrastructure costs by 30–50%. They can also ensure seamless migrations between HA tiers without causing downtime. Begin by scheduling an independent audit of your current architecture.

Active-Active vs Active-Passive Cluster to Achieve High Availability in Scaling Systems

FAQs