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?

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. Option A (circuit breaker) 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. Option C (fixed intervals) is worse than exponential backoff because all clients on fixed intervals will remain synchronized. Option D (global retry coordinator) 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.