A service depends on four components, each independently 99.9% available, called in sequence on every request. What is the resulting availability, and what does this imply about architecture?

The arithmetic

Serial dependencies multiply: 0.999⁴ ≈ 0.996. Unavailability roughly quadruples — from about 43 minutes a month to nearly three hours.

The general form: each hard dependency added to a request path makes the path less available than its weakest component. A service cannot be more reliable than the product of everything it must call.

What this implies

1. Count your hard dependencies, and treat the count as an architectural metric. A request path touching ten services, each at 99.9%, is capped at roughly 99% — about seven hours of unavailability per month, before any of your own code fails. Most teams have never computed this number for their critical path, and are surprised by it.

2. Convert hard dependencies into soft ones. This is the highest-leverage move available. A dependency with a fallback — cached data, a default, a degraded experience — does not multiply, because its failure no longer fails the request. Turning one hard dependency into a soft one is usually worth more than making three dependencies more reliable.

3. Redundancy adds where dependencies multiply. Two independent replicas at 99.9% give 1 − (0.001)² = 99.9999%, provided the failures are genuinely independent. They rarely are: shared network, shared power, shared configuration, shared deployment, shared bug. The measured benefit of redundancy is almost always far below the theoretical one, and the gap is a function of correlation.

4. The dependency you forgot dominates. DNS, certificate validation, identity, configuration, service discovery, the container registry. These are usually absent from the diagram and present in the failure.

The practical exercise

For your most critical path, list every component whose failure fails the request — including infrastructure — and multiply. The result is the ceiling on your availability regardless of how much redundancy you add to any single component.

Then, for each dependency, ask the more productive question: what would we serve if this were unavailable? Every satisfactory answer removes a term from the product, and that is how availability targets are actually met.

The lesson that catches teams out

Adding a service to improve reliability frequently reduces it. A new health-checking component, a new routing layer, a new feature-flag service — each is a well-intentioned addition that becomes a hard dependency on the critical path and lowers the ceiling. Any component on the critical path must either be more available than your target, or be optional.