Request-Count Amplification

A team reports 99.9% per-request availability and is pleased with it. A typical session makes about 150 requests. The probability that a whole session succeeds is 0.999^150 ≈ 0.86, so roughly 1 session in 7 sees at least one error.

"99.9% available" is read by almost everybody as "one user in a thousand has a problem". The real figure here is 140 times worse, and the difference is arithmetic rather than a measurement defect.

Why it matters

Users experience journeys, not requests. This single conversion explains the most common disagreement in SLO reviews, where every engineering metric is green and customer satisfaction is not. Nobody is wrong; the number being reported is not the number being felt.

It also reorders the work. The session failure rate is approximately request count × error rate, so halving the calls per journey improves user-visible reliability exactly as much as halving the error rate — and halving the calls is usually a frontend or API-shape change costing days, while halving the error rate is an infrastructure programme costing quarters.

And it reframes retries correctly. A retry that succeeds converts a request failure into additional latency rather than a journey failure, which is why client-side retry with jitter is one of the cheapest reliability improvements available: it acts directly on the exponent.

Implementation patterns

• Publish the request count per journey next to any availability target. Without it the target cannot be translated into experience, and it will be mis-read.
• Set the SLO on the journey. "Checkout completes" is what the business cares about and what a user notices; per-request availability is an input to it.
• Count the whole chain. A journey crossing 4 services at 99.9% each is already about 99.6% per request before session length is applied.
• Weight by importance. If 149 of 150 calls are background telemetry and one is the payment, compute over the calls whose failure the user would notice. A naive exponent over all requests overstates the problem.
• Attack the exponent first: fewer calls per journey, batched or aggregated endpoints, idempotent operations so retries are safe, and client retries with jitter and a retry budget.
• Track calls per journey as a metric. It grows silently as features are added, so user-visible reliability degrades with no change in any service's availability.

Industry example

The reasoning is the stated basis for journey-level and critical-user-journey SLOs in Google's SRE practice, published from 2016: targets are set on what a user is trying to do, precisely because per-request numbers for individual services do not compose into an experience anybody recognises.

The counter-pattern is equally well documented in mobile engineering. A screen that issues 9 sequential calls on load is a reliability liability as well as a latency one, which is the capacity argument for a backend-for-frontend or a single aggregated endpoint. Collapsing 9 calls to 1 reduces the exponent by a factor of 9 and is often a week of work — though it trades one failure mode for another, since the aggregate call cannot answer without its dependencies unless it degrades per field.

Failure scenarios

• A green SLO beside rising complaints, with nobody able to reconcile them.
• A retry storm. Retries consume the same capacity as first attempts, so without a retry budget a partial outage becomes a full one.
• Non-idempotent retries that double-charge or double-book, converting a reliability feature into a correctness defect.
• Silent erosion: features add calls per journey over a year, and session reliability falls while every service dashboard stays flat.
• Over-correction, where an aggregated endpoint is introduced with no per-field fallback, so one slow dependency now fails the whole screen.

Trade-offs

When not to use it

When requests are not independent. If 150 calls all depend on one failing service, they fail together and the exponent does not apply — the journey failure rate is the service's failure rate. Multiplying there produces a frightening number that describes nothing.

Also not for a journey dominated by one critical call. Compute over the calls the user would notice failing, and say which those are; a weighted journey SLI is more useful than either the raw per-request figure or a naive exponent over everything.

Interview question

Q: Your API reports 99.95% availability and has met its SLO for a year. Support volume about failed operations is rising. The mobile team says the app is unreliable. Where do you start?

What a strong answer covers: converting per-request to per-session using the measured call count per journey, and presenting that number rather than the SLO · measuring calls per journey and its trend, since it grows silently with features · checking whether failures are independent or concentrated in one dependency, because the arithmetic differs · the two levers with their costs: reducing calls per journey is usually the cheaper one, and client retries with jitter act on the exponent but need idempotency and a budget · moving the SLO to the journey level so the metric and the complaint are about the same thing · and the caution against a naive exponent when one call dominates the journey's importance.

Quick check

Quiz: At 99.9% per request and 150 requests per session, what share of sessions see an error? — About 14%, since 0.999^150 ≈ 0.86; the shortcut is request count × error rate while that product stays under about 0.3.

Flashcard: Which is cheaper — halving the error rate or halving the calls per journey? — Almost always halving the calls. Both improve session reliability by the same factor, and one is an API change while the other is an infrastructure programme.