High Availability (HA)

The foundational principle of HA is redundancy, which involves duplicating every critical component of a system so that a backup can immediately take over if the primary fails. This eliminates Single Points of Failure (SPOFs)—any component whose failure would cause the entire system to stop.

• Examples: Multiple web servers behind a load balancer, replicated databases across availability zones, redundant power supplies and network paths.
• Implementation: Requires careful analysis of the entire stack—hardware, software, network, and even personnel—to identify and mitigate all potential SPOFs.

Redundancy is ineffective without automated failover—the process of automatically switching to a standby system upon detection of a failure. This is enabled by health checks and probes that continuously monitor component status.

• Key Mechanisms: Liveness probes restart unresponsive containers; readiness probes remove unhealthy pods from service traffic; database replication with automatic primary promotion.
• Goal: Minimize Mean Time To Recovery (MTTR). The system should detect, isolate, and route around failures without human intervention, enabling self-healing architectures.

Distributing incoming requests across multiple, redundant instances prevents any single instance from being overloaded, improving both performance and availability. This is managed by load balancers and sophisticated traffic shaping policies.

• Traffic Splitting: Directing a percentage of traffic to different service versions for canary deployments or A/B testing.
• Rate Limiting & Circuit Breakers: Protect backend services from being overwhelmed by excessive requests or cascading failures, preserving availability for legitimate users.

A truly HA system is designed to fail gracefully. When a non-critical component fails, the system should isolate the fault and continue operating with reduced functionality, rather than crashing entirely. This is also known as implementing a bulkhead pattern.

• Example: If a product recommendation service is down, an e-commerce site should still allow users to view products, add them to a cart, and checkout, perhaps displaying a static "Popular Items" list instead.
• Benefit: Maintains core user functionality during partial outages, preserving user trust and business continuity.

Protection against data center or regional outages requires multi-region or multi-cloud deployment. This involves replicating applications and data across geographically dispersed locations.

• Active-Active: Traffic is load-balanced across all regions simultaneously for lowest latency and maximum throughput.
• Active-Passive (DR): A standby region is kept synchronized and activated only if the primary region fails.
• Challenge: Requires solving data replication, consistency models, and global traffic routing (e.g., using GeoDNS).

You cannot manage what you cannot measure. HA relies on comprehensive observability—collecting metrics, logs, and traces—to understand system state and predict issues before they cause outages.

• Service Level Indicators (SLIs): Quantitative measures of service performance (e.g., latency, error rate, throughput).
• Service Level Objectives (SLOs): Target values for SLIs that define "availability." Breaching an SLO triggers alerts and remediation efforts.
• Chaos Engineering: Proactively testing resilience by injecting failures (e.g., killing instances, adding latency) in a controlled manner to validate HA design assumptions.

The duplication of critical components or functions of a system with the intention of increasing reliability. In HA design, redundancy is implemented to eliminate single points of failure.

• Active-Active: Multiple identical systems process traffic simultaneously, increasing capacity and providing instant failover.
• Active-Passive: A primary system handles all traffic while one or more standby systems remain idle, ready to take over if the primary fails.
• Geographic Redundancy: Systems are replicated across multiple data centers or cloud regions to protect against large-scale regional outages.

The automatic process of switching to a redundant or standby system upon the failure or abnormal termination of the previously active system. Failover is the reactive mechanism that makes redundancy functional.

• Automatic vs. Manual: Automatic failover is essential for minimizing downtime, while manual failover may be used for planned maintenance.
• Stateful vs. Stateless: Stateful failover requires replicating session data (e.g., user shopping carts) to the standby node, adding complexity. Stateless failover is simpler as any node can handle any request.
• Failover Time: The Recovery Time Objective (RTO) dictates the maximum acceptable duration for this process.

A set of policies, tools, and procedures to enable the recovery or continuation of vital technology infrastructure and systems following a natural or human-induced disaster. DR is a broader discipline that encompasses HA.

• Recovery Point Objective (RPO): The maximum tolerable period of data loss, measured in time (e.g., 5 minutes of transactions).
• Recovery Time Objective (RTO): The maximum tolerable duration of downtime (e.g., 2 hours).
• HA vs. DR: High Availability focuses on minimizing downtime during minor, frequent faults (server failure). Disaster Recovery focuses on restoring operations after a major, catastrophic event (data center destruction).

The property that enables a system to continue operating properly in the event of the failure of one or more of its components. While HA aims to minimize downtime, fault tolerance aims to prevent it entirely.

• Hardware Fault Tolerance: Uses specialized hardware with built-in redundancy (e.g., RAID arrays, dual power supplies).
• Software Fault Tolerance: Achieved through design patterns like replication, consensus algorithms (e.g., Raft, Paxos), and idempotent operations.
• Key Difference: A fault-tolerant system has no service interruption during a component failure. A highly available system has a brief, often imperceptible, interruption during failover.

A critical networking component that distributes incoming application traffic across multiple backend servers (a pool or cluster). It is a foundational element for achieving both scalability and high availability.

• Health Checks: Continuously monitors backend servers and stops sending traffic to unhealthy instances.
• Traffic Distribution Algorithms: Uses methods like round-robin, least connections, or IP hash to efficiently route requests.
• Eliminates Single Points of Failure: Load balancers themselves are deployed in HA pairs (active-active or active-passive) to prevent the balancer from becoming a bottleneck.

Formal metrics and commitments that define the expected availability and performance of a system. They are the business and engineering targets that HA architecture is designed to meet.

• Service Level Agreement (SLA): A formal contract with customers that includes availability guarantees (e.g., 99.9% uptime) and consequences (penalties) for breaching them.
• Service Level Objective (SLO): An internal, engineering-focused target that is stricter than the SLA (e.g., 99.95% uptime) to provide a safety margin.
• Service Level Indicator (SLI): The specific measurement used to calculate availability, such as the ratio of successful requests to total requests over a period.