Running a Service That Stays Up
A Chain of Reliable Parts Is Not Reliable
Last timeWhere the Measurement Is Taken
Availabilities multiply along a chain, so a service standing on ten dependencies cannot be more reliable than their product, however good its own code is.
A service is usually written as though it were one thing. It is not. It is the
last link in a chain, and the chain has an arithmetic that does not care how
carefully the last link was written.
- the availability of one part, when all the parts are alike
- how many parts the request passes through
What a second copy buys
Redundancy works on the failure rather than on the availability, and that is why
it is powerful.
- the availability of the pair, which is everything except the case where both are down
- the probability that both copies are unavailable at the same moment, each being down with probability one minus its availability
The word that does all the work
The squaring above is a consequence of one assumption, stated quietly:
independence. The two copies must fail for unrelated reasons.
The lesson stops here
4 more paragraphs to go
You have read the opening. The rest of the argument, the problems that check whether it landed, and the lines worth keeping at the end all come with a plan.
The first lesson of every course in the library reads the whole way through, free, so you can see exactly what the rest of them are.
See the planThe contentsThis is the reading half
Starting the course gives you your own copy of it. Every idea on every page has problems standing under it, marked with a reason rather than a tick, and any sentence you do not believe can be opened and argued with. None of that can happen on a page nobody owns.
The contents