Module 02 · Lesson 04
Availability and the nines
Each nine costs roughly ten times as much as the one before it.
What you will be able to do
- Convert an availability figure into allowed downtime
- Compute the availability of serial and redundant components
- Explain why replication does not equal availability
- Challenge an availability target that the business has not paid for
| Target | Per year | Per month | Engineering reality |
|---|---|---|---|
| 99% | 3.65 days | ~7 hours | One server, manual recovery |
| 99.9% | 8.8 hours | ~43 minutes | Health checks, replicas, real deploys |
| 99.95% | 4.4 hours | ~22 minutes | Multi-AZ, automated failover, on-call |
| 99.99% | 53 minutes | ~4 minutes | Multi-region or exceptional single-region operations |
| 99.999% | 5 minutes | ~26 seconds | Active-active regions, dedicated reliability staff |
The arithmetic that surprises people
Serial dependencies multiply. A request that must pass through five services at 99.9% each succeeds about 99.5% of the time — which is 3.6 hours of downtime a month even though every component looks healthy on its own dashboard.
serial: 0.999 x 0.999 x 0.999 x 0.999 x 0.999 = 0.9950 (99.50%) five healthy services -> about 3.6 hours per month of failure redundant: 1 - (1 - 0.999)^2 = 0.999999 (99.9999%) two independent instances -> nine seconds per month, in theory but only if failover is automatic and the pair is truly independent.
There are two levers and only two: reduce the number of things in series, and make the redundant path real. The second is where designs quietly fail, because two instances in the same rack, sharing a power feed and a network switch, are one instance with extra steps.
Replication is not availability
A standby replica that requires a human to promote it adds an hour of downtime per incident, not zero. Automated failure detection plus automated promotion is what turns a spare copy into availability — and both halves must be tested, or the first real incident is also the first test.
Designing to the number you were given
Ask what the product loses per minute down
Checkout, payments and a status page have very different price tags. A dashboard nobody watches at 3 a.m. can be at 99% and cost nothing.
Spend effort on the serial path, not everywhere
Find the longest chain a request must traverse and shorten it. Caching, precomputation and async work remove hops; adding replicas to a hop nobody waits on does not help.
Make degradation explicit
Recommendations unavailable? Serve a cached list. Search down? Serve recent items. A system that loses one feature at 99.9% behaves better than one that returns errors at 99.99%.
Q. Is multi-region always the right step after multi-AZ?
No. Multi-region solves region loss, which is rare, and introduces cross-region consistency problems, which are constant. Usually the better next step is removing a serial dependency or making writes idempotent. Justify multi-region with a real requirement, not with a number on a slide.
Worth remembering
- Serial components multiply: five dependencies at 99.9% each give about 99.5% end to end.
- Redundancy without automated failover is a diagram, not availability.
- 99.9% is 43 minutes a month; 99.99% is 4 minutes. The second is a different organisation, not a different config.
- Availability is a budget you spend, not a badge. Design to the number the product needs.
Checkpoint
Answer all 2 questions to finish the lesson.
1. Three serial dependencies each at 99.9% availability give roughly what end-to-end availability?
0.999 cubed is about 0.997, so 99.7%. Serial failure probabilities compound — this is why long call chains are a reliability decision, not just a latency one.
2. What turns a standby replica into actual availability?
Without automatic detection and promotion, recovery depends on a human noticing, which is measured in tens of minutes. A same-rack replica shares the failure you were defending against.