Concept questionMedium~7 min

Interview question

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 Retry-After 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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would set a retry budget as a small fraction of normal traffic and disable or reduce retries when dependency latency, throttling, or error rate crosses a threshold. Jitter distribution, maximum backoff, and concurrency limits matter as much as attempt count. I would expose attempts, final outcomes, retry-added latency, throttled retries, and duplicate-prevention results in telemetry. Load and failure tests would prove that recovery traffic ramps gradually after an outage instead of creating a second spike, and runbooks would name which policies can be changed safely during an incident.

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.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Retry count is unlimited.
400, 401, and business failures are treated as transient.
Retry volume is invisible in telemetry.
Recovery from an outage sends all delayed work at once.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Which HTTP responses would you retry?
Why is a timed-out POST ambiguous?
How can nested retries multiply traffic?
What would a retry budget measure?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Go deeper

Practice the next layer of the same subject.

Circuit Breakers

Concept questionMedium~7 min

Interview question

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

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 Retry-After 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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would set a retry budget as a small fraction of normal traffic and disable or reduce retries when dependency latency, throttling, or error rate crosses a threshold. Jitter distribution, maximum backoff, and concurrency limits matter as much as attempt count. I would expose attempts, final outcomes, retry-added latency, throttled retries, and duplicate-prevention results in telemetry. Load and failure tests would prove that recovery traffic ramps gradually after an outage instead of creating a second spike, and runbooks would name which policies can be changed safely during an incident.

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.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Retry count is unlimited.
400, 401, and business failures are treated as transient.
Retry volume is invisible in telemetry.
Recovery from an outage sends all delayed work at once.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Which HTTP responses would you retry?
Why is a timed-out POST ambiguous?
How can nested retries multiply traffic?
What would a retry budget measure?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Go deeper

Practice the next layer of the same subject.

Circuit Breakers

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 practice

Go deeper

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 practice

Go deeper