A dependency degrades. Your service retries three times with exponential backoff. The dependency never recovers until you deploy a change. Why?

What the interviewer is testing

Whether you understand retry amplification and the specific role of jitter.

The mechanism

Retries multiply load on a system that is already saturated. Three attempts per request means the struggling dependency receives up to three times the traffic exactly when it has least capacity. It gets slower, more requests time out, more retries are issued. The loop is self-sustaining and the dependency cannot recover while the load persists.

Backoff without jitter makes it worse. All callers failed at roughly the same moment, so all wait 1 second, all retry simultaneously, all fail, all wait 2 seconds, and retry together again. The dependency is hit by synchronised waves perfectly designed to prevent recovery.

Retries compound across layers. Three layers each retrying three times is 27 requests for one user action.

The fixes

Full jitter — choose the delay uniformly between zero and the current backoff ceiling. This spreads retries into an absorbable trickle rather than spikes, and it is the variant that performs best in published analyses.

Circuit breakers, so after a threshold of failures the caller stops attempting entirely and gives the dependency room to recover. This is what actually breaks the loop.

Retry budgets — cap retries as a percentage of total requests (commonly around 10%), so retry traffic cannot dominate. This is more robust than per-request attempt limits because it bounds the aggregate.

Retry at one layer only. Decide where retries happen and disable them everywhere else, or the multiplication returns.

Deadline awareness: do not retry when there is no time left in the budget for the retry to help.

What a strong answer adds

The dependency's own protection: it should shed load rather than degrade for everyone, returning 429 or 503 quickly so callers back off, and prioritising by request class. A system that has no way to say "stop" relies entirely on its callers behaving well.

And the general principle: any periodic behaviour synchronised across a fleet becomes a spike — cron on the hour, identical cache TTLs, aligned health checks, token refreshes. Add jitter to all of them.

Common weak answers

Removing retries entirely, which loses genuine transient recovery. Increasing backoff without jitter.