Retry Budget
Capping retries as a proportion of overall traffic rather than as a count per request, so retries cannot multiply during the failure they are meant to survive.
"Three attempts" is the standard configuration and it has a specific pathology: it multiplies load by three at precisely the moment a dependency is struggling. Chain it across three layers and one user action becomes twenty-seven requests.
A retry budget inverts the control. The client tracks the ratio of retries to original requests across a rolling window and refuses to retry once that ratio exceeds a threshold — commonly around 10%. In normal operation almost nothing retries, so the budget is never touched. During an incident the budget is exhausted immediately and retries stop, which is exactly the behaviour you want and the opposite of what a per-request count produces.
Combine with jittered exponential backoff (spreading in time), a deadline budget (so no retry is attempted without room to succeed) and retry-at-one-layer-only (so the multiplication cannot happen at all). Together those four turn retries from an amplifier into a genuine resilience mechanism.