Retries with a budget, not a count

Retries with a budget, not a count

The naive answer is "retry three times." The senior answer is a retry budget: cap retries as a fraction of total traffic so that when a provider fails broadly, retries can't multiply load and turn a partial outage into a total one.

1. 1Classify the failure. Only retry what the normalized taxonomy marks retryable - a 503 or a timeout, never a 400 or a content-policy refusal.
2. 2Back off with jitter. Exponential backoff plus randomization spreads the retry wave so a thousand clients don't all retry on the same tick.
3. 3Spend from a global budget. If retries exceed, say, 10% of requests, stop retrying and shed - the provider is broadly down, not blipping.
4. 4Cross over, don't just repeat. A retry that targets the same dead provider is wasted; route the retry to the next provider on the ladder.