Skip to main content
Availability Nineslesson 3 of 3 · 3 min read

The Math of Redundancy

The arithmetic in reverse

Redundancy runs that same arithmetic in reverse. If either of two independent copies can serve the request, you fail only when both fail.

Two nodes at 99.9 percent each, so each carries a one in a thousand chance of being down. Both down together is one in a million, which makes the pair 99.9999 percent available. One duplicate bought you three extra nines.

The asymmetry is the entire it is the entire economic case for replicas and multiple regions. Chaining things costs you a little. Putting them in parallel pays enormously.

The formula generalises: with several copies each failing with some probability, your availability is one minus that probability raised to the number of copies. Three unimpressive 99 percent servers in parallel give 99.9999 percent. Cheap unreliable things in parallel beat expensive reliable things standing alone, and that is what commodity cloud hardware was built on.

The fine print

Now read the fine print, because interviews and production both punish people who stop at the formula. It assumes failures are independent, and real failures correlate.

What your copies share matters. Two replicas in one rack share a switch. Two availability zones share a region's control plane. And every copy shares your deploy pipeline and your configuration, which matters because bad deploys and bad config cause more outages than hardware ever does. Your two 99.9 percent nodes are one careless config push from failing together.

Failover has an availability of its own. Detection takes time, the switchover itself can fail, and a standby you have never exercised is a prayer rather than a plan. Model it as the parallel formula discounted by detection time and by how often failover actually works. That is why serious teams run practice drills: redundancy you have not tested rounds down to zero.

the shape of it
Load balancerReplica A99.9%Replica B99.9%Pair99.9999%either patheither path
step 1 of 2
With either copy able to serve, both must fail at once, and 0.001 squared is one in a million.

Worked example

Sofia runs infrastructure for a ticketing platform whose single Postgres primary at 99.9 percent keeps blowing the SLA during big on-sales. She adds a hot standby with automated failover and presents the naive math: two 99.9s in parallel is 99.9999 percent, about 31 seconds a year. Her SRE lead makes her test it. In the first game day, failover takes 4 minutes: health checks required three consecutive failures at 30-second intervals, and the standby then refused connections because of a stale config file nobody had exercised. They tighten detection to 20 seconds, fix the config drift, and add a monthly automated failover drill. Real failovers now complete in about 40 seconds, and the pair delivers roughly 99.99 percent. Short of the formula's six nines, 10 times better than one box, and every minute of the gap is explained by measurements instead of hope.

Availability Nines: wrapping up

In the real world

  • 01AWS S3 is designed for 99.999999999 percent durability (eleven nines) but carries an availability SLA of 99.9 percent, the standard example that durability and availability are different promises.
  • 02Google's SRE book rejects 100 percent as a target and formalizes error budgets: the gap between the SLO and perfection is a budget teams spend on releases, and a burned budget freezes deploys.
  • 03AWS pays EC2 SLA credits at the region level only when instances run in multiple availability zones, pricing the independence assumption of parallel availability directly into the contract.
  • 04The February 2017 S3 outage in us-east-1 broke thousands of unrelated products for about 4 hours, a public demonstration of correlated failure through a shared dependency.
  • 05Telephone switching was the original five nines requirement, and carrier-grade platforms like Erlang/OTP were built at Ericsson specifically around that target.

Questions people ask

What is the difference between availability and durability?

Availability is whether the system answers right now; durability is whether the data still exists eventually. S3 makes this vivid: eleven nines of durability but a 99.9 percent availability SLA. An outage can make your objects unreachable for hours without losing a single byte. You buy availability with redundant serving paths and durability with redundant storage and backups.

Does any product actually need five nines?

A few do: emergency services, telephony, core payment networks, air traffic systems. Most consumer and SaaS products do not, because their clients, ISPs, and devices fail more often than a four nines backend does. If the user's wifi provides two nines, paying for five on the server is spending money below the noise floor.

Why does my system fail more often than the SLA math predicts?

Almost always correlated failure. The parallel formula assumes copies fail independently, but real replicas share deploy pipelines, configs, certificates, DNS, and cloud regions. A bad deploy or an expired certificate takes out every copy at once, which no amount of multiplication predicted. Config pushes and cert expiry belong in your failure model alongside hardware.

Quick review

99% (two nines):
87.6 hours/year downtime, not acceptable for production
99.9% (three nines): 8.76 hours/year. Typical for many SaaS products
99.99% (four nines): 52.6 minutes/year. Requires automated failover
99.999% (five nines): 5.26 minutes/year. Requires active-active multi-region + zero-downtime deploys
AWS S3:
99.999999999% durability (eleven nines). Durability ≠ availability. S3 availability SLA = 99.9%
Composite SLA:
two 99.9% services in sequence = 99.9% × 99.9% = 99.8%. Add redundancy to improve
Parallel availability:
two 99.9% services in parallel (either can serve) = 1 - (0.001)² = 99.9999%
the trade-off

Five nines requires multi-region active-active. Very expensive and complex. Match to actual business requirement.

in the room

Define SLO before designing redundancy. Each additional nine costs disproportionately more.