A production API service makes Claude calls and encounters a mix of 429 (rate limit), 500 (server error), and 529 (overloaded) responses. The engineering team is implementing retry logic. They observe that under sustained load, naive exponential backoff with identical retry intervals causes synchronized retry storms across 200 concurrent client instances, amplifying the 529 errors. What retry strategy resolves this?
Select an answer to reveal the explanation.
Short Explanation
Here's the deal — retry storms happen when clients all back off on the same schedule. Add full jitter so each client picks a random delay between 0 and the backoff ceiling, which spreads retries out and desynchronizes the herd without coordination.
Full Explanation
The thundering herd / retry storm problem is specifically caused by synchronized retry timing across multiple clients. Full jitter (random delay in [0, computed_ceiling]) breaks this synchronization without requiring coordination between clients. Each client independently randomizes its delay, spreading retry attempts across the backoff window and reducing instantaneous load spikes. The circuit breaker that stops retries for 60 seconds when 529 errors exceed 10% of requests reduces load during outages but doesn't solve the synchronization problem — when the circuit closes after 60 seconds, all 200 clients simultaneously resume with a new retry storm. The fixed 2-second retry intervals are worse than exponential backoff because all clients on fixed intervals will remain synchronized. The global retry coordinator service that serializes retries across the 200 client instances, spacing them 100ms apart, solves the synchronization problem but introduces a single point of failure, a performance bottleneck, and significant operational complexity where a simple algorithm change (full jitter) would suffice.