A production API integration is experiencing 529 Overloaded errors during peak traffic periods despite being within published rate limits. An architect is tasked with improving reliability. Which combination of strategies is most appropriate?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal — 529 Overloaded errors indicate temporary server-side capacity constraints, not client-side rate limit violations. The correct response is: (1) exponential backoff with jitter to spread retry load and avoid thundering herd, (2) client-side concurrency limiting to prevent request pile-up during recovery, and (3) using the Batches API for workloads that don't require real-time responses, which offers better availability guarantees during peak loads.
Full explanation below image
Full Explanation
529 Overloaded errors indicate temporary server-side capacity constraints, not client-side rate limit violations. The correct response is: (1) exponential backoff with jitter to spread retry load and avoid thundering herd, (2) client-side concurrency limiting to prevent request pile-up during recovery, and (3) using the Batches API for workloads that don't require real-time responses, which offers better availability guarantees during peak loads. Option B (fixed 1-second retry intervals) causes thundering herd behavior and will worsen overload conditions. Option C (response caching) is valid for identical requests but doesn't address the underlying overload handling architecture. Option D is incorrect — 529 errors are not model-specific capacity issues; switching models does not resolve server-side overload.