High Availability (HA)

High availability is engineering against downtime as a design property, not a hope: redundant components, automatic failover, and no single point whose failure stops the service. HA is why some systems weather failures users never notice — and it is quantified, contracted and priced in nines.

What It Is

High availability is a system's ability to remain operational through component failures, achieved by redundancy (multiple instances of everything that matters — servers, network paths, power, entire data centres or availability zones), failure detection, and automatic failover: when a component dies, traffic reroutes without human intervention. Availability is quantified in the nines (99.9%, 99.99%...) measured over a window, with the design question always 'which failure are you surviving?' — one zone down is standard; an entire region down demands cross-region architecture at materially higher cost and complexity. HA is distinct from disaster recovery (see below) — HA survives failures continuously; DR recovers from the catastrophic ones HA cannot absorb.

Why It Matters to You

HA is where technology risk becomes financial engineering: each additional nine reduces allowable downtime by an order of magnitude and multiplies cost — which is why the honest conversation is never 'make it highly available' but 'what does an hour of downtime cost, and which failure scenarios are we paying to survive?'. In vendor and cloud engagements, HA claims decompose into specifics: how many availability zones, what fails automatically, what still needs humans, and what the client's own dependency (connectivity, power) does when the vendor's side is fine. Uptime history at reference customers beats any architecture slide.

When You'll Meet It

In contracts, architecture reviews, and business-continuity planning. Convert HA claims to scenarios: 'if a data centre fails tonight, what do my users experience, for how long, and who does what?'