High Availability

N+1, N+2, the redundant-component formula, and why a single 99.9% box stays a single 99.9% box.

Overview

Redundancy buys the nines

High availability is not "buy a more reliable box." A single 99.9% server is a 99.9% server. The only way past per-component reliability is redundancy plus automated failover, and the math is unforgiving.

The formulas (AWS Well-Architected Reliability Pillar)

Hard dependencies, in series — Availabilities multiply — Three independent 99.99% components: 99.99³ is about 99.97%
Redundant components, in parallel — Avail = 1 − failure_rate^N — Two 99.9% replicas: 1 − 0.001² = 99.9999%

> [!IMPORTANT] The duplication is what buys the 9s. Every hard dependency in series takes some back.

Redundancy levels

N — Minimum replicas for normal load — Nothing: one failure means capacity loss
N+1 — One spare; industry baseline — One replica failure with no capacity loss
N+2 — Two spares; required for tight SLOs — A failure during a maintenance window (one out for upgrade, another fails)

Independent failure domains

The SRE Book's Ch 23 caution: redundancy works only if components have independent failure domains.

Same rack — Power, network, cooling, noisy neighbors
Across availability zones — Survives a single-AZ outage
Across regions and providers — Produces the math you actually want

> [!WARNING] Two replicas in the same rack are not really independent. The parallel formula only holds when failures are independent.

Key concepts

Hard-dependency math: Components in series: Avail = ∏ Avail_i. Three 99.99% deps → 99.97% effective. Series chains REDUCE availability.
Redundant-component math: Components in parallel: Avail = 1 − failure_rate^N. Two 99.9% replicas → 99.9999%. Parallel INCREASES availability — this is why redundancy works.
N / N+1 / N+2: N = minimum replicas. N+1 = one spare (tolerates one failure). N+2 = two spares (tolerates failure during maintenance). Industry baseline is N+1; tight SLOs need N+2.
Independent failure domain: Two redundant components must not share power, network, cooling, software bugs, or operator error. Two replicas in one rack are NOT independent.
AWS availability table (canonical): 99% = 3d 15h/yr · 99.9% = 8h 45m · 99.95% = 4h 22m · 99.99% = 52 min · 99.999% = 5 min downtime per year.

When to use it

Designing for an SLO above ~99.95% — single-machine reliability won't reach it
Writing the capacity-planning doc — N+1 is the floor, N+2 for any meaningful SLO
Justifying multi-AZ / multi-region cost to product or finance
Reviewing an architecture proposal — does the redundancy actually have independent failure domains?

Interview questions

A service has three independent dependencies, each 99.99% available. What's its effective availability?
Why does N+1 redundancy not always give you "two 9s more"?
When do you actually need N+2 instead of N+1?
Recite the AWS availability-to-downtime table.