Availability Is Multiplication
Availability is multiplication is the rule that a path requiring several components is available only when every required component is available, so their probabilities are multiplied only if those component events are independent. The phrase is a warning: the arithmetic is simple, but the independence assumption is the hard part.
The problem is that system availability is usually a property of a whole request path, not of one service. A user may need DNS, a load balancer, application code, storage, authentication, and a network route to work at the same time. If any required dependency is down, the request fails. Engineers want one number for the path, but combining component numbers naively can produce comforting nonsense.
The mechanism comes from probability. The event “the path works” is the intersection of the events “each required component works”. For independent events, the probability of that intersection is the product of the individual probabilities. For redundant replicas, you usually flip to failure probabilities: the redundant group is down only if every replica is down, so independent failure probabilities multiply, then you take the complement.
The trade-off is that multiplication is only valid under independence, which means learning that one event happened does not change the probability of the other. That is a strong claim in production systems. Pods on the same node, services using the same database primary, or regions relying on the same authentication endpoint can fail together. Common misunderstanding: more replicas do not automatically mean independent replicas.
Engineers meet this when reading service level objectives, designing failover, reviewing architecture diagrams, and deciding whether redundancy is real or cosmetic. Anti-affinity, topology spread, multi-zone placement, separate control planes, and distinct providers are attempts to reduce shared causes. The honest answer to “can I multiply these availabilities?” is: it depends on the failure modes and whether any dependency couples them.
Common questions
- When is it correct to multiply component availabilities?
- It is correct when the system needs all of those components to work and their availability events are independent. In practice, that means a failure in one component must not make another more or less likely to fail. Shared hosts, shared databases, shared networks, shared configuration, and shared control planes usually weaken or break that assumption.
- Why do redundant systems use failure probabilities instead of availability probabilities?
- A redundant group is unavailable only when every usable copy fails. That is an intersection of failure events, so under independence you multiply the failure probabilities. Then you subtract that result from certainty to get availability. Adding availability values is wrong, because probabilities cannot exceed the whole sample space.
- What is the most common mistake in availability arithmetic?
- The common mistake is treating colocated or shared-dependency components as independent because they are separate processes, pods, instances, or services. If one node failure, database outage, DNS issue, regional control-plane problem, or bad configuration change can take them down together, the simple multiplication does not describe the real system.