errors-reliabilityAnswer last reviewed July 2026

A call to a downstream service fails. How do you retry it without making things worse?

A strong answer treats retries as a system property, covering classification, jitter, budgets, and idempotency, not just a loop with a sleep in it

What an AI-prepared candidate might say

Basically you retry with exponential backoff and you cap the attempts. So wait one second, then two, then four, and give up after three to five tries or so. You add jitter, which is just a random component in the delay, so that a bunch of clients that failed at the same moment don't all come back at the same moment. And you only retry errors that are probably transient, like timeouts and 503s, and only on operations that are idempotent, where running them twice is harmless. For writes that aren't naturally idempotent there's the idempotency key thing, which lets the server deduplicate. Honestly libraries handle most of this for you, and a circuit breaker on top stops retrying entirely when the dependency looks properly down. The main things to avoid are retrying forever and hammering a service that's already struggling.

Senior
Locked

How to classify what's retryable, full jitter versus plain exponential, per-attempt AbortSignal timeouts, and why a timed-out write is nothing like a refused connection.

Unlock the depth
Staff
Locked

The amplification math when every layer retries, retry budgets, and the idempotency-key mechanics that make retrying a charge actually safe.

Unlock the depth
Follow-up chain
A call to a downstream service fails. How do you retry it without making things worse? | NodeBook