A single server, however reliable, will eventually go down: hardware faults, kernel updates, a bad deploy, a full disk, a network incident. High availability (HA) means designing so that no single failure takes your service offline. It costs more servers and more complexity, so it’s worth understanding what each layer needs, and how far to go.

First: how much availability do you need?

Availability Downtime per year Typical approach
99% ~3.65 days One server, backups, quick restore
99.9% ~8.8 hours One good server, monitoring, fast recovery, maybe a warm standby
99.95% ~4.4 hours Redundant app servers, replicated database with failover
99.99% ~53 minutes Redundancy at every layer, automated failover, multi-zone
99.999% ~5 minutes Multi-region active-active, serious engineering

For many businesses, one well-run server plus tested backups (99.9%) is the right trade-off. Measure the cost of downtime before buying complexity. See the 3-2-1 backup rule.

The layers of an HA web stack

            DNS (anycast provider, health-checked)
                         │
        Load balancers ×2 (floating IP / failover)
                         │
        App servers ×2+  (stateless)
                         │
   Database primary ── replica (automatic failover)
   Cache / sessions (Redis with replica or Sentinel)
   Files: object storage or replicated storage

1. DNS

Use a managed DNS provider with anycast nameservers. Your own single nameserver would be a single point of failure. Health-checked DNS failover can switch between sites. See nameservers explained.

2. Load balancers

Two load balancers (Nginx or HAProxy) with a floating IP via keepalived, or provider-managed failover IPs. See keepalived floating IP and load balancer types.

3. Stateless application servers

App servers must be interchangeable, so any can handle any request:

  • sessions in Redis or the database, not local files. See install Redis;
  • uploads to object storage (S3-compatible, such as MinIO) or a shared, replicated store, not the local disk. See MinIO;
  • identical deploys to all servers (CI/CD, Ansible). See CI/CD explained;
  • health check endpoints the load balancer can probe.

4. Database

The hardest part, because it holds state:

  • Primary + replica(s) with streaming replication. See MySQL replication and PostgreSQL replication.
  • Automatic failover: Patroni (PostgreSQL), Orchestrator or MySQL Group Replication / InnoDB Cluster, or a multi-primary cluster like Galera. See MariaDB Galera cluster.
  • Apps connect through a stable endpoint: a VIP, HAProxy or a proxy (ProxySQL, PgBouncer) that follows the current primary. See HAProxy TCP mode.
  • Understand replication lag and what happens to recent writes during failover.

See database replication explained.

5. Cache and queues

Redis with a replica and Sentinel (or Redis Cluster), or treat the cache as disposable, so the app works, slower, without it. Message queues (RabbitMQ, Redis streams) need their own HA setup.

6. Files and storage

Shared filesystems (NFS) are often a single point of failure themselves. Prefer object storage with built-in redundancy, or replicated systems (GlusterFS, Ceph) if you must, accepting their operational cost.

Failure domains

Redundant servers on the same physical host or in the same rack can fail together. Spread critical pairs across:

  • different hosts (ask your provider about anti-affinity, or use dedicated servers in different racks);
  • different data centres or regions for disaster recovery. For example, primary in Los Angeles, standby in another location. See choosing a VPS location.

Multi-region adds latency between components. Synchronous database replication across oceans is usually impractical, so use asynchronous replication and accept a small data-loss window, or design region-local data.

Monitoring and alerting

HA without monitoring just means failures go unnoticed until the second one. Monitor every node, replication lag, the failover state and certificate expiry, and alert on degraded redundancy, not only on total outage. See Prometheus and Grafana and Uptime Kuma.

Test failover regularly

Untested failover often fails when it’s needed. Schedule drills:

  • stop the primary load balancer, and watch the VIP move;
  • reboot an app server during traffic;
  • promote a database replica on staging, and rehearse failing back;
  • restore from backup into a clean environment.

Maintenance without downtime

With redundancy in place, you can patch and reboot one node at a time, deploy with rolling or blue-green strategies, and upgrade databases with replicas. See blue-green deployments and patch management.

A practical starting point

  1. One solid server + off-site backups + monitoring (most small sites).
  2. Add a warm standby server with a replicated database, and a documented manual failover.
  3. Add two app servers behind a load balancer, with sessions in Redis and files in object storage.
  4. Add automatic database failover and load balancer redundancy.
  5. Add multi-region for disaster recovery.

Related: vertical vs horizontal scaling and ransomware protection.

  • High Availability
  • Architecture
  • VPS Guides