A request passes mobile client, edge gateway, orchestration service and pricing service. Each layer retries twice on failure, three attempts in all, with jittered exponential backoff. Roughly how much load does pricing see during a partial degradation, and what does a retry budget actually cap?

The assumptions, stated

One user action. Three retrying layers above pricing (client, gateway, orchestration). Each makes up to 3 attempts. Pricing is degraded rather than down, so attempts are consumed - they take time and capacity and then fail.

The arithmetic

Attempts multiply down the stack, because each layer's retry is a fresh request that the layer below also retries:

client 3  ×  gateway 3  ×  orchestration 3  =  27 attempts at pricing per user action

Add a fourth retrying hop and it is 81. Remove one and it is 9. The exponent is the number of retrying layers; the base is attempts per layer. Depth dominates.

So a degradation that halves pricing's success rate does not raise its load by a factor of two. At steady user demand it raises it by up to 27 times, and the range matters less than the order of magnitude: anything above about 3 means the retry mechanism is now the load.

Which assumption dominates the error

Not the per-layer count - the depth, and specifically whether a layer gives up when the caller's deadline has passed. With deadline propagation, upper layers stop retrying when there is no budget left, and the effective multiplier collapses towards the innermost layer's count. Without it, every layer spends its full allowance against a deadline that expired long ago, and the work is not just amplified, it is worthless when it completes.

What the number rules out

Retrying at more than one layer. The rule that follows: retry at exactly one layer - the one that knows the user's deadline - and make every layer below it fail fast. Jitter and exponential backoff change the shape of the 27, not its size; they stop synchronised bursts and do nothing about total volume.

What a retry budget caps

A retry budget expresses retries as a ratio of normal traffic rather than a count per request: with a 10% budget, the subsystem may issue one retry for every ten first attempts, and drops retries beyond that. Amplification is bounded at about 1.1 times instead of 27, and the bound holds no matter how many callers are failing at once - which per-request counts never do. Envoy's retry budgets and gRPC's retry throttling both express it this way, and the metric to graph is retry ratio, not retry count.

When this is the wrong answer

For a cheap idempotent read with a hard 50 ms budget and no layers below it, a second hedged attempt fired at p95 is the right design: it raises load by a few percent and cuts tail latency sharply. Budgets and single-layer rules matter when calls are expensive, deep or non-idempotent. A one-hop read path does not have an amplification problem to solve.