Fallback, retry and graceful degradation

What the system does when the happy path is unavailable.

4 min read · Lesson 11 of 12 in this domain

A retry strategy is not just "try again". It is a decision about whether the operation can succeed on repetition, how many times to attempt it, how long to wait between attempts, and what to do when attempts are exhausted. Blind immediate retries are the worst of all worlds: they hammer a struggling dependency and turn a brief outage into a longer one. Exponential backoff with jitter is the standard shape because it spreads retry load instead of synchronising it. And every retry policy needs a terminal branch — a fallback that degrades gracefully, or an escalation, because "retry forever" is not a strategy.

• Retry only what can succeed on repetition. Permanent errors — bad arguments, missing records, denied permissions — will fail identically every time.
• Use exponential backoff with jitter so concurrent clients do not retry in lockstep and amplify the outage.
• Bound retries explicitly. The SDKs retry connection errors, 408, 409, 429 and 5xx with backoff by default; a typical default is two attempts.
• Honour retry-after on a 429 rather than guessing an interval.
• Define the terminal branch: degrade to a partial answer, route to a fallback path, or escalate — but decide it in advance rather than looping.
• Graceful degradation beats total failure: returning three of five enrichment fields with the gap flagged is usually better than returning nothing.

Source: Claude Docs — Tool use overview · Independent study aid, not affiliated with or endorsed by Anthropic.