Sree Vardhan VandClaude Opus 5.5
ac8ddd654c
Rewrite the topic copy to reflect current practice: retry only transient failures (timeouts, 429, 502-504), cap retries, use exponential backoff with jitter, respect Retry-After, and retry only idempotent requests. The old copy suggested retrying until a request succeeds, which can cause retry storms. Add three resources on backoff, jitter and Retry-After. No other topic in the API Design, Backend or AI Engineer roadmaps covers these yet. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
1.6 KiB
Error Handling / Retries
Error handling and retries decide how an API and its clients behave when something goes wrong. On the server, good error handling means validating input early, returning the correct HTTP status code (4xx for client mistakes, 5xx for server faults) and a consistent, machine-readable error body, such as the Problem Details format, so clients can react programmatically. On the client, only transient failures like timeouts, 429 Too Many Requests, 502, 503 and 504 are worth retrying, while errors such as 400 or 404 will fail again. Retries should be capped, spaced out with exponential backoff and jitter so many clients don't retry at the same moment, respect the Retry-After header when the server sends one, and be used only for idempotent requests (or ones protected by an idempotency key) so a repeated call can't cause duplicate side effects.
Visit the following resources to learn more:
- @article@Timeouts, retries, and backoff with jitter - AWS Builders' Library
- @article@Exponential Backoff and Jitter - AWS Architecture Blog
- @article@Retry-After header - MDN
- @article@How To Improve Your Backend By Adding Retries to Your API Calls
- @video@How to Make Resilient Web Applications with Retries