Asked about Back-of-envelope numbers
Your service calls eight internal dependencies. Each promises 99.9 per cent. What can you promise?
An answer that works
Not 99.9. Availability multiplies, so 0.999 to the eighth is about 99.2 per cent, which is around 4,200 minutes of downtime a year. To promise more than my dependencies I have to stop depending on all of them for every request: make the optional ones degrade rather than fail, cache what can be served stale, and add redundancy where the copies genuinely fail independently.
Then they push further
One of the eight is at 99 per cent. Where do you spend your effort?
On that one, and the arithmetic says so rather than instinct: with one dependency at 99 per cent the chain cannot exceed 99 per cent however good the others are. Fixing it or removing it from the critical path dominates any improvement elsewhere.
Why does adding a third redundant copy help so little?
Because after two copies that dependency is no longer the limit. Two independent copies at 99 per cent give 99.99 per cent, at which point the other services dominate the total, and improving something that is not the bottleneck does nothing.
What gets marked up
Strong answers multiply rather than quote the weakest link, and name degradation as the route to being more available than your dependencies.
Reading an answer is not being able to give one. The section that teaches this is Back-of-envelope numbers, 3 hours of Distributed systems.
Learn this properlyAlso asked about Distributed systems