Use the RxJS retry operator with a delay function for exponential backoff. The delay function receives the error and the retry count — return a timer Observable with increasing delay. After all retries are exhausted, publish the failure to a dead-letter topic for manual review rather than silently dropping it.

Exponential backoff retry with RxJS and dead-letter fallback

Retry strategy design rules:

1
Add random jitter to the delay — prevents thundering herd when many clients retry simultaneously.
2
Exponential backoff: delay = 2^(retryCount - 1) * baseMs — doubles the wait on each attempt.
3
After all retries are exhausted, emit to a dead-letter topic rather than silently discarding.
4
Pair retries with a circuit breaker — retries without a circuit breaker amplify load on a failing service.
5
Only retry on transient errors (timeouts, connection refused) — do not retry on 400 Bad Request.

Difficulty: 5/10

Topics: exponential backoff, NestJS interceptors, retry configuration

Scenario Questions

0-2 years experience

1
We have a NestJS service that calls an external payment API. How would you add exponential backoff retries to that HTTP call?
2
If the third retry still fails, what would you return to the controller, and how would you ensure the client gets a proper error?

2-5 years experience

1
During a recent release, retries started causing a cascade of delayed requests and timeouts. Walk me through how you'd debug and adjust the backoff parameters.
2
Explain the trade‑offs between using a NestJS interceptor versus a custom wrapper service for implementing retries.
3
How would you make the retry count and backoff base configurable per endpoint without redeploying?

5-8 years experience

1
Our system processes 10k requests per second and we need retry with exponential backoff. How would you design the retry mechanism to avoid overwhelming downstream services and keep latency low?
2
Describe how you would integrate circuit breaker patterns with exponential backoff in NestJS, and what metrics you would monitor.
3
If a downstream service returns HTTP 429 with a Retry‑After header, how would you combine that with your exponential backoff strategy?

8+ years experience

1
We are migrating several microservices from a monolith to NestJS and need a unified retry/backoff policy across teams. How would you architect a shared library or framework to enforce consistent behavior?
2
Discuss the long‑term maintenance implications of hard‑coding backoff values versus using feature flags or a centralized config service.
3
How would you evaluate the impact of exponential backoff on overall system throughput and SLA, and what strategies would you propose to mitigate any negative effects at scale?

Follow-up Questions

❓What would you do to prevent thundering herd problems when many requests retry simultaneously?
❓How do you test that your backoff logic works under failure conditions?
❓Can you explain how you'd expose the retry settings for ops to tune without code changes?