Services in a chain
When a request needs every component to be up, multiply their availabilities:
A = A1 × A2 × ... × AnA web app at 99.95% that needs a database at 99.95% and DNS at 99.99% has at most 99.89% availability. That is 9h 37m 59s of downtime a year, against 4h 22m 48s for either 99.95% part alone. A chain is always less available than its weakest link, and every dependency you add lowers the ceiling.
Redundant services
When any one of several copies can serve the request, the system is down only when all of them are down at once:
A = 1 - (1 - A1) × (1 - A2) × ... × (1 - An)Two independent copies at 99.9% each give 99.9999% in theory. That is a ceiling, and real redundancy delivers less.
The independence trap
The parallel formula assumes the copies fail independently. Google Cloud's reliability guide makes the same point: two resources at 99.9% give 99.9999% in theory, but the real figure is capped by the zone or region they share. Copies that share a region, a power feed, a deploy pipeline, a configuration file or a DNS provider tend to fail together, and then the real figure sits much closer to that of a single copy. Failover also takes time: if switching to the spare takes two minutes, every failure still costs two minutes.
Treat the formula as an upper bound. Measure the whole path from outside, the way users reach it, to find the real number.
Mixed systems
Real systems mix both. Work out each redundant group first with the parallel formula, then multiply the groups in the chain. Two load-balanced app servers at 99.9% each (99.9999% together) in front of a single database at 99.95% give 99.9499%. The single database sets the limit, which is usually where the next improvement should go.