High Availability architecture removes single points of failure through redundancy at every tier. HA differs from DR: HA tolerates component failure inside one site; DR tolerates site / region loss.
10.2 High Availability Architecture
HA vs DR
Property
HA
DR
Scope
Within a site / region
Across sites / regions
Failure tolerated
Component
Site or region
Typical RTO
Sub-second to seconds
Minutes to hours
Cost driver
Redundant components
Replicated capacity
Patterns at each tier
Tier
HA pattern
Network
Dual ISP + BGP; HSRP / VRRP gateways
Load balancer
Active-active LB pair
Web / app
N+1 or N+M; auto-scaling
Database
Primary + replicas; auto-failover
Storage
RAID + cluster filesystems; replicated
Power
Dual feeds; UPS; generator
Cooling
N+1 CRAC units
Database HA - two patterns
Pattern
Behaviour
Primary / replica
One writes, replicas read; replica promotes
Multi-primary
All write; conflict resolution required
Engine
HA tech
PostgreSQL
Patroni + repmgr
MySQL
InnoDB Cluster, Galera
MongoDB
Replica set with priority + arbiter
Oracle
Data Guard + RAC
Worked example - small bank web tier
Tier
HA configuration
LB
Two F5 in active-active
App
Four Spring Boot instances; scale to 8 on peak
DB
Postgres primary + 2 replicas in same region
Cache
Redis Sentinel cluster
DNS
Multi-A record + TTL 60 sec
Failover
Sub-second for app; ~30 sec for DB promotion
Observability for HA
Signal type
Tools
Health checks
LB + service mesh
Synthetic monitoring
Checkly, Pingdom
Distributed tracing
OpenTelemetry, Jaeger
SLO + error budget
Grafana SLO, Sloth
Saturation alerts
Prometheus + Alertmanager
Common pitfalls
HA components on the same power circuit.
Replica with stale data during writes.
Load balancer is itself a single point of failure.
Failover never tested; the day it matters, it does not work.
Mentor’s tip: HA inside; DR across. Every tier needs redundancy and a tested failover. SLO + error budget makes the trade-off explicit. Untested failover is the default cause of long outages.
Discussion
Loading…