Availability in Chains

Chained services multiply

When a request passes through several services and any one failure fails the request, their availabilities multiply.

Work it through. Two services at 99.9 percent in series give 99.8. Your chain is now less available than either link, and it degrades quickly with length: five services at 99.9 percent give about 99.5 percent, which is over 43 hours of expected downtime a year, built entirely from parts that each promised under nine.

This is the quiet tax on microservices. Every synchronous dependency multiplies another number below one into your availability. A single application calling its own functions pays nothing. A request fanning out through authentication, profiles, pricing and a database pays it four times.

The arithmetic does not tell you to avoid microservices. It tells you that every synchronous hop must either be more available than your target or be removable from the critical path. Cache its answer, make it asynchronous, or degrade gracefully when it is down.

Compute your ceiling before building, because managed services publish these numbers. Compose an application from a gateway at 99.95 percent, compute at 99.95, a database at 99.99 and object storage at 99.9, and your product is about 99.79 percent, roughly 18 hours a year.

Your architecture diagram is an availability formula. Your promise is the product of the boxes, not the smallest one.

What blunts the tax

Two things blunt the tax. Dependencies off the synchronous path do not multiply, so a queue between you and something flaky turns its downtime into delay instead of failure. And graceful degradation reclassifies failures: if your recommendation service being down means people see a generic list rather than an error, its nines drop out of the formula entirely.

// Each team hit 99.9%. Checkout depends on all five, so the
// probabilities multiply rather than average.
double chained = 1.0;
for (Service s : List.of(auth, catalogue, pricing, payments, email)) {
  chained = chained * s.availability();      // 0.999 each
}
// chained = 0.995, which is 43 hours down a year, not 8.

// Redundancy runs the same arithmetic backwards: two copies fail
// only when both fail at once.
double pair = 1 - Math.pow(1 - 0.99, 2);     // 0.9999

Worked example

Ravi's team at an e-commerce company investigates why measured checkout availability is 99.6 percent when every service dashboard shows green at 99.9 or better. He draws the request path: checkout synchronously calls cart, inventory, pricing, a payment gateway, and Postgres. Six components at roughly 99.9 percent multiply to 0.999 to the sixth power, about 99.4 percent, so the measurement isn't a monitoring bug, it's arithmetic. The team attacks the chain instead of the components. Pricing gets a 5-minute cache with stale-while-revalidate, so its outages stop failing checkouts. Inventory moves to an async reservation model with a queue. That leaves three multiplicative terms instead of six, and measured checkout availability climbs to 99.85 percent the next quarter without any individual service getting more reliable.