When should an API retry a failed dependency call, and how do you keep retries from making an outage worse?

Retry transient dependency failures without causing a retry storm

Classifies retryable outcomes and applies bounded attempts, exponential backoff, jitter, deadlines, and idempotency.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would retry only failures that are plausibly transient, such as a connection reset, selected timeouts, 429, or some 5xx responses. Validation errors, authentication failures, and deterministic business rejections should not be retried. Attempts must be few, bounded by the remaining deadline, and delayed with exponential backoff plus jitter so callers do not retry in lockstep. Side effects require an idempotency key or another durable deduplication boundary before automatic retry is safe.

Full answer below

Practice focus

Transient-failure classification, idempotency, exponential backoff, jitter, retry budgets, deadlines, and overload protection.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A retry can recover a brief transient failure, but it also multiplies traffic during the exact moment a dependency has the least spare capacity.
I would retry only failures that are plausibly transient, such as a connection reset, selected timeouts, 429, or some 5xx responses. Validation errors, authentication failures, and deterministic business rejections should not be retried. Attempts must be few, bounded by the remaining deadline, and delayed with exponential backoff plus jitter so callers do not retry in lockstep. Side effects require an idempotency key or another durable deduplication boundary before automatic retry is safe.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Retry policy belongs at the boundary that understands the operation. A fast read may tolerate one or two attempts, while a timed-out write may have an unknown result and should be queried or reconciled instead of repeated blindly. I would respect when it is trustworthy, stop when the caller's budget is exhausted, and avoid stacking retries in the client, API, SDK, and database driver. One layer should own the attempt budget so three logical attempts do not become dozens of physical calls.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Retrying every exception.
Retrying a timed-out mutation without idempotency.
Nesting retries at several service layers.
Using fixed delays with no jitter.
Starting another attempt after the request deadline is exhausted.

When should an API retry a failed dependency call, and how do you keep retries from making an outage worse?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Technologies

Tech stacks

Skill areas

Suggest an improvement