Retries spend more work during a failure#
Retries can recover from transient connection errors, brief unavailability, some server failures, and policy-approved throttling responses. Repeating malformed input, failed authorization, or a permanent constraint violation usually changes nothing.
A simplified retry storm
10,000 original + 10,000 retry 1 + 10,000 retry 2
≈ 30,000 attempts/secThis worst-case illustration ignores timing and successful attempts, but exposes the amplification risk. Cap attempts and elapsed time, honor the request deadline, and use a retry budget so callers cannot create unlimited recovery traffic.
- Retrying every error.
- Retrying at several layers and multiplying attempts.
- Retrying a side effect before making the operation idempotent.
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- Timeouts, retries, and backoff with jitterAmazon Builders' Library
- Addressing cascading failuresGoogle SRE
Reach this point to mark the lesson as read.