If a request needs any one of several independent paths, it fails only when all of them fail, so A = 1 − ∏(1 − Aᵢ): two 99% paths give 99.99%. That formula assumes the switch between paths is instantaneous, which it never is. Charging the failover time against the result is usually a larger correction than anything a further replica would buy.
Core ideas
The complement turns an AND into an OR, and then reality adds a term that no amount of redundancy removes.
A set of paths serving the same request is up unless every one of them is down. Under independence P(all down) = ∏(1 − Aᵢ), so A = 1 − ∏(1 − Aᵢ). Two paths at 99% fail together with probability 1/10 000 and the pair is 99.99%; a third path makes it 1/10⁶ and 99.9999%. Each replica multiplies the unavailability by the next one's.
In series, each component divides the availability; in parallel, each replica multiplies the unavailability by a number well below one. That is why redundancy looks like such a good deal on paper — four paths at 99% are eight nines — and why the paper number is almost never the one a system achieves.
Detecting the failure, agreeing on it and cutting over takes seconds, and those seconds are downtime the formula never mentions. Twelve failovers a year at thirty seconds is six minutes a year, flat. At two paths that is a tenth of the ideal outage; at four paths it is essentially all of it, and the fifth replica buys nothing measurable.
The material
Why the complement is the right way to compute an OR, what each replica is worth, and where the returns actually stop.
Components are in parallel for a request when any one of them can serve it. If they fail independently, the whole is unavailable only when all are, so 1 − A = ∏ᵢ (1 − Aᵢ) and A = 1 − ∏ᵢ (1 − Aᵢ). Computing the complement is not a trick: it converts an OR over many events, which has inclusion-exclusion terms, into an AND, which does not.
Two nines plus two nines is four nines, in parallel — and it is worth being precise about why, because the same reader who adds nines here will add them in series, where the claim is false in the other direction. In parallel the unavailabilities multiply, and 10⁻² × 10⁻² is 10⁻⁴. In series the unavailabilities add.
The formula describes a system that notices a failure instantly and switches with no loss. Real cutovers take a health check, a timeout, a decision and a reconnection, and every second of that is a second the request did not get served. The correction is arithmetic: failover seconds × events per period ÷ period, subtracted.
Six minutes a year, and it does not shrink when a replica is added, because it is not a property of the replicas — it is a property of the switching. That is what makes it dominate so quickly.
With a thirty-second failover happening twelve times a year: two paths at 99% give a real 99.988858%, three give 99.998758%, four give 99.998857%. The ideal figures over the same range go from four nines to eight; the real ones have essentially stopped by three, because the ideal outage has fallen below the six minutes of switching and the fourth replica is improving a term that is no longer the largest one.
Three things, and each is a separate way to be disappointed. That the paths fail independently, which is the next lesson and the largest of the three. That any single path can carry the whole load — if two paths each run at 60% of capacity, losing one does not leave a working system, it leaves an overloaded one. And that the redundancy is exercised: a standby that has never served a request is a component with an unmeasured availability, and it is not 0.99.
A cache is added in front of a database to make reads faster, and the client is written so that a cache error fails the request. The reader calls it redundancy because there are now two data stores. The request needs both, so it is a series chain: 0.999 × 0.999 = 99.80010%, below the database alone. Adding a component raises availability only when the request can succeed without it, and that is a property of the client's error handling rather than of the topology drawing.
Interactive
Two 99% paths give 99.99% — if they are independent and the switch is free
Method
Compute the ideal, then subtract what the mechanism costs, then check the three assumptions. The subtraction is usually the biggest number on the page.
A request must be able to succeed using any one of them alone. If the client fails the request when one errors, or if one path holds data the other does not, they are in series and the formula for this lesson is the wrong one.
P(all down) = ∏(1 − Aᵢ) and A = 1 − P(all down). Two paths at 1/100 give 1/10 000. Working in unavailabilities keeps the exact digits: 1/10 000 is legible where 0.9999 is nearly 1.
failover seconds × events per period ÷ period, subtracted from the ideal. Estimate the event rate from how often the paths actually fail rather than from how often you plan to test, and include every cutover, including the ones that turned out to be unnecessary.
If the failover charge already exceeds the ideal unavailability, another replica cannot help: it shrinks a term that is no longer the largest. Spend the effort on detecting failures faster or switching more cleanly instead.
Regional redundancy with a slow cutover, which is the common case: the paths are very good and the switching is not.
Six nines on the slide, four in the year, and twelve times as many seconds of outage as the formula promised — all of it spent switching. The direction this points is clear: cutting the cutover from ninety seconds to ten is worth far more here than a third region, which would improve the 31.54 seconds and leave the six minutes alone.
For a faded rehearsal, keep two regions and suppose the team can either add a third region or halve the failover to 45 seconds. The supplied first move is to write the two terms separately — the ideal unavailability and the charge — and see which one each option touches. Compute both resulting availabilities in the lab, then say which you would buy and what you assumed about the regions failing independently.
You should be able to compute 1 − ∏(1 − Aᵢ) exactly, convert a failover policy into seconds a year, subtract it, identify the replica count at which the switching dominates, and say which components in a drawing are genuinely parallel for a given request.
Something to change about this lesson? Write it down, tick it off when it is handled, and export the list when you want to act on it. Kept in this browser only: nothing is sent anywhere, and nobody is notified.
No recommendations yet for this lesson.