Retry Strategies

The modern retry({ count, delay }) configuration object form (replacing the older, more manual retryWhen) lets you specify a fixed number of attempts and, critically, a delay — either a fixed number of milliseconds or a function computing a delay per attempt, which is how you implement exponential backoff (waiting progressively longer between each retry attempt) to avoid hammering an already-struggling server with immediate, rapid-fire retries.

An important interview-level nuance is that a naive retry() with no configuration retries immediately and indefinitely on every single error, which is almost always the wrong default for production code — it can turn one failing request into a tight retry loop that makes an already-degraded backend worse, which is exactly why the count and delay options (or a custom retryWhen predicate in older code) exist and should essentially always be used deliberately rather than left at defaults.

A thorough answer also distinguishes retry from catchError: retry re-attempts the exact same failed operation from scratch hoping for a different outcome, while catchError accepts the failure and substitutes something else entirely — the two are frequently combined, with a bounded retry attempting a few automatic recovery attempts first, and a catchError as the final fallback if all retries are exhausted and the operation is still failing.