A platform receives bursts of 500 requests per second to the Claude API and observes intermittent 529 (overloaded) and 529 errors that are distinct from 429 rate limit errors. The team's current retry logic uses a fixed 1-second delay. What retry strategy should replace this?
Select an answer to reveal the explanation.
Short Explanation
Here's the deal — exponential backoff with jitter is the right retry strategy because it handles transient API overload without synchronized retry storms. You add random jitter so many clients do not all retry at once, and you cap the delay so waits stay bounded.
Full Explanation
The correct strategy is exponential backoff with jitter: on each retry attempt, wait base_delay * (2^attempt) + random(0, base_delay) seconds, capped at a maximum delay of 60 seconds. This is the standard recommended pattern for handling transient API overload. Pure exponential backoff without jitter causes synchronized retry storms when multiple clients all wait the same delay; jitter spreads retries across a time window, reducing thundering-herd pressure on the API. Capping at a maximum prevents indefinite waits. This is explicitly recommended in Anthropic's API documentation for handling both 429 and 529 errors. The fixed 30-second delay strategy is wrong because it does not solve the retry storm problem — all clients still retry at the same time after 30 seconds; it only shifts the storm. The secondary geographic endpoint routing strategy is wrong because Anthropic does not expose multiple geographic endpoints that clients can route between; 529 errors are API-level overload conditions, not region-specific failures that routing can circumvent. The strategy that disables automatic retries entirely and surfaces 529 errors to callers as rate limit exceptions is wrong because disabling retries in the platform layer and pushing responsibility to callers increases integration complexity and results in a worse client experience; the platform should handle transient errors transparently.