Design the timeout configuration for a request that passes through gateway, orders, pricing and inventory. What numbers, and what rule generates them?

The rule that generates the numbers

One budget at the edge, decreasing inward, with room for a retry at exactly one layer.

Start from what the caller will actually wait for — say a 3-second total for a user-facing request. Then work inward, leaving each layer enough margin to do its own work plus handle a slow callee.

A worked configuration

Two things this encodes. Orders gets a timeout that permits two attempts at pricing within its own budget — retries are placed at one layer, chosen because Orders knows the user's deadline. And each hop's timeout is strictly less than its remaining budget, so a slow callee cannot cause the caller to blow its own promise.

Why per-hop constants fail

Four services each configured with 30 seconds produce a two-minute worst case. Worse, the outer caller times out first and retries while the inner hops are still working on the original request — so load doubles precisely when the system is struggling.

Timeouts that increase as you go inward are the specific configuration that guarantees this, and they are common because each team picks a value that seems generous for their own dependency.

Implementation

Propagate an absolute deadline in a header (gRPC does this natively; over HTTP it is a convention). Each service computes its remaining budget on entry and declines immediately if the work cannot fit — returning capacity rather than spending it on a request nobody is waiting for.

Derive each timeout from the callee's measured p99, not a round number, and re-derive when the callee's latency distribution changes.

What a strong answer adds

Pairing the deadline with a retry budget — retries capped as a share of traffic rather than as a count — so that during an incident the retries stop rather than multiplying. Deadlines bound wasted work; retry budgets bound amplification. You need both.