A public-health backend hits transient Claude HTTP 429 responses. Which resilience practice fits?
Select an answer to reveal the explanation.
Short Explanation
A 429 is a yellow light, not a cue to replay queued calls on a fixed timer—that can stampede the API. Back off with jitter and retry the idempotent Claude calls.
Full Explanation
Public-health backends that hit transient Claude HTTP 429 responses should retry idempotent Claude requests with jitter. Resilient retry with backoff and jitter fits because 429 indicates temporary rate limiting rather than a permanent application fault: spaced retries share recovery capacity fairly and avoid synchronized stampedes when many clinic workers retry at once. Idempotent requests are safe to re-issue without duplicating harmful side effects. Replaying queued Claude requests at fixed intervals during 429 bursts fails by concept: fixed intervals can synchronize retries into a stampede and ignore backoff, making rate limiting worse. Raising concurrent Claude throughput to clear the 429 backlog faster fails by concept: adding concurrency while rate limited multiplies the load and provokes more 429s instead of clearing the backlog. Extending client timeout windows for rate-limited Claude calls fails by concept: longer timeouts do not respond to the rate-limit signal; they just hold connections open and delay the needed backoff. Exam caveat: retries must respect Retry-After when provided, cap maximum attempts, and escalate to a degraded clinic workflow when limits persist—and non-idempotent side-effecting calls need careful deduplication keys rather than naive replay. Operational check: inject 429 responses in a public-health staging client, verify retries use exponential backoff with jitter, confirm success on a subsequent 200, and verify the client surfaces a controlled error after exhausting the retry budget instead of hanging.