Retries are how a healthy service turns a partial outage into a total one. The Google SRE fix — later shipped in Envoy and gRPC — is a retry budget: allow no more than budget × successful RPS retries per client per rolling window, with a minimum floor. When the origin is healthy, the ratio is negligible. When the origin is dying, retries are capped at the fraction the origin can spare — no cascading failure, and the client still gets the tail-latency win under normal conditions.
Amplification factor is origin_rps / client_rps during the outage. A naïve max_attempts=3 policy hits 3× when every request fails and retries twice. A retry budget caps this at 1 + budget ≈ 1.2× for a 20% budget.
Min-retries floor matters when the client is low-volume — with 5 RPS at 20%, the budget alone allows only 1 retry/sec, so a single flaky burst can't retry at all. The floor lets small clients still get transient-error retries without penalising the origin at scale.
Rolling window should be short (5–30 s) — longer windows let retries "borrow" from stale success history and let cascade recovery lag behind reality.
Effective success rate is the % of user requests that eventually succeed, including exhausted retries. A budget trades a small drop here (during outage) for a big drop in origin load — the point is keep the origin alive so it can recover, not maximise short-term success.