Cascading Timeout
The effect of independently-chosen per-hop timeouts summing to a total far longer than any caller is willing to wait.
Four services in a chain, each configured with a "sensible" 30-second timeout, produce a worst case of two minutes. The user gave up after five seconds, the browser gave up after thirty, and the system spends the remaining ninety seconds doing work whose result nobody will receive.
Worse, the outermost caller times out first, so it retries — while the inner hops are still processing the original request. Load doubles at exactly the wrong moment.
The structural fix is a deadline propagated from the edge rather than per-hop constants: the edge sets a total budget, each hop passes the remaining time, and any service that cannot finish within what remains fails immediately instead of starting work that is already doomed.
Where a deadline is not available, the rule of thumb is that each hop's timeout must be meaningfully shorter than its caller's, leaving room for the caller to retry or degrade. Timeouts that increase as you go inward are the specific configuration that guarantees this failure.