Your Availability Is the Product of Everything a Request Must Touch
A single component's availability figure tells you almost nothing about the service a user experiences, because a request usually passes through several components and any one of them can refuse it. When components are arranged so that all of them must work, their availabilities multiply. Four things at 99.9 percent in a row give roughly 99.6 percent, which is about three hours of downtime a month rather than forty-three minutes. Nobody plans this; it arrives by accident, one dependency at a time. Redundancy composes the other way: for copies arranged so that any one is enough, it is the unavailabilities that multiply, so two copies at 99 percent give about 99.99 percent. That is the entire arithmetic, and it produces two design moves. Shorten the chain, by removing a dependency from the request path or making it optional so a failure degrades the answer instead of refusing it. Or duplicate the weakest link. Both multiplications assume the components fail independently, and that assumption is usually the first thing to break: a shared power supply, a shared network, a shared configuration push or a shared bug fails everything at once and the parallel arithmetic cannot see it. You can now compute the availability a proposed design actually offers and name which dependency is costing the most.
This Concept is waiting for its first lesson!
A single component's availability figure tells you almost nothing about the service a user experiences, because a request usually passes through several components and any one of them can refuse it. When components are arranged so that all of them must work, their availabilities multiply. Four things at 99.9 percent in a row give roughly 99.6 percent, which is about three hours of downtime a month rather than forty-three minutes. Nobody plans this; it arrives by accident, one dependency at a time. Redundancy composes the other way: for copies arranged so that any one is enough, it is the unavailabilities that multiply, so two copies at 99 percent give about 99.99 percent. That is the entire arithmetic, and it produces two design moves. Shorten the chain, by removing a dependency from the request path or making it optional so a failure degrades the answer instead of refusing it. Or duplicate the weakest link. Both multiplications assume the components fail independently, and that assumption is usually the first thing to break: a shared power supply, a shared network, a shared configuration push or a shared bug fails everything at once and the parallel arithmetic cannot see it. You can now compute the availability a proposed design actually offers and name which dependency is costing the most.
Are you a teacher? Sign in to start contributing.
Sign In