High Availability Setup — Keep Your Application Running When Things Break

High availability means your application continues serving requests when individual components fail. The standard metric is "nines" — 99.9% uptime (8.7 hours downtime/year), 99.95% (4.4 hours), 99.99% (52 minutes). Each additional nine is exponentially harder and more expensive to achieve. Most web applications should target 99.95%, which is achievable with standard cloud architecture.

HA requires redundancy at every layer of the stack. A single point of failure anywhere — one application server, one database, one load balancer, one availability zone — means the entire system goes down when that component fails. We eliminate single points of failure systematically: multiple application instances behind a load balancer, database with automatic failover, multi-AZ deployment, and health checks that route around failures.

Redundancy alone is not enough. You also need detection (health checks that identify failed components within seconds), failover (automatic routing around failed components), and recovery (failed components restart or are replaced automatically). Without all three, redundant components sit idle while the failed component takes down the service.

The most overlooked aspect of HA is deployment safety. Your architecture might survive a server crash, but does it survive a bad deployment? Rolling deployments, health check validation, and automatic rollback ensure that deployments are not the leading cause of downtime.

Multi-AZ Compute: We deploy your application across at least two availability zones. ECS services or Kubernetes deployments spread tasks/pods across AZs via placement constraints. If an entire AZ goes down (rare but happens), the remaining AZs handle all traffic. We set minimum healthy percent to ensure at least N-1 AZs worth of capacity is always running.

Database Failover: RDS Multi-AZ deploys a synchronous standby replica in a different AZ. When the primary fails, RDS automatically promotes the standby. The failover takes 60-120 seconds. We configure your application's connection pooler (PgBouncer) to handle the DNS change transparently. For Aurora, failover takes 30 seconds or less with reader endpoint failover built in.

Health Checks: We implement multi-layer health checks. The load balancer checks application health every 10 seconds and removes unhealthy targets within 30 seconds. The application health endpoint checks database connectivity, Redis connectivity, and critical external services. Kubernetes liveness probes restart crashed pods. Readiness probes remove pods from service during startup or degradation.

Circuit Breakers: When an external dependency fails (third-party API, payment processor, email service), a circuit breaker stops sending requests after N consecutive failures, returns a fallback response, and periodically retries to detect recovery. This prevents cascade failures where one slow dependency makes your entire application unresponsive. We implement circuit breakers at the HTTP client level using libraries like opossum (Node.js) or resilience4j (Java).

Zero-Downtime Deployments: We configure rolling deployments with health check validation. New instances are added, verified healthy, and only then old instances are drained and removed. If the new version fails health checks, the deployment stops and rolls back automatically. We also configure connection draining so in-flight requests complete before instances are terminated.

A highly available infrastructure architecture:

• Multi-AZ deployment — compute, database, and cache distributed across availability zones
• Automatic failover — database, cache, and DNS failover configured and tested
• Health checks — multi-layer health monitoring at load balancer, application, and dependency levels
• Circuit breakers — fault isolation for external dependencies with fallback responses
• Zero-downtime deployments — rolling updates with health validation and automatic rollback
• Connection draining — graceful request completion during instance rotation
• Disaster recovery plan — documented RTO/RPO targets with tested recovery procedures
• HA testing — chaos engineering experiments to validate failover behavior