Availability Composition
How the availability of a system follows from its dependencies — multiplying for serial dependencies and improving sharply for redundant ones.
The arithmetic every architect should be able to do at a whiteboard, because it disposes of unachievable targets before they are committed to.
Serial dependencies multiply. A service requiring five dependencies each at 99.9% has a ceiling of 0.999^5 ≈ 99.5%, which is roughly 43 hours of downtime a year rather than the 8.8 hours the individual figures suggest. Adding dependencies degrades availability, always, and this is the strongest quantitative argument against a design with a long synchronous call chain.
Redundant components improve it sharply. Two independent instances at 99% give 99.99%, because both must fail simultaneously — provided the failures are genuinely independent, which is the assumption that usually breaks. Two instances of the same code with the same bug, in the same zone, behind the same load balancer, sharing a database, are not independent, and the arithmetic silently overstates the result.
The design consequences that follow directly: reduce hard dependencies in the request path; make dependencies soft with a fallback so their failure degrades rather than fails; and put redundancy where the correlation is genuinely low.
The conversation this enables is the valuable one. When a stakeholder asks for 99.99%, the response is to enumerate the dependencies and show what the composition permits, which turns an aspiration into a costed engineering programme or a revised target.