Timeouts, novas tentativas e recuo exponencial com jitter

In a Node.js backend, every call that leaves your process (HTTP request, database query, message broker publish) is a place where you can hang forever. A slow dependency does not just delay one request, it pins an event-loop tick, holds a socket, and keeps a connection-pool slot busy.

• Unbounded latency cascades: one stuck downstream call multiplies into thousands of stuck inbound requests.
• Resource exhaustion: sockets, file descriptors, and pool connections leak while you wait.
• No SLA without a deadline: you cannot promise a p99 latency if a call has no upper bound.

The first rule of production resilience: never make an outbound call without a timeout. Retries and backoff build on top of that bound.

Modern Node.js (18+) ships AbortSignal.timeout(ms), which produces a signal that aborts automatically after the deadline. The global fetch accepts a signal, so bounding an HTTP call is a one-liner.

• When the timeout fires, the promise rejects with an AbortError (err.name === 'AbortError').
• The signal is fire-and-forget: no manual clearTimeout needed.
• Always distinguish a timeout abort from other network errors so you log and retry correctly.

"Timeout" is not a single number. A robust client distinguishes several deadlines:

• Connect timeout: how long to wait for the TCP/TLS handshake.
• Read / socket-idle timeout: how long to wait between bytes once connected.
• Total / overall timeout: a hard wall on the entire operation, including retries.

A common bug is setting only a read timeout. A dependency that accepts the connection but never sends the first byte can still stall up to the socket-idle limit. The total budget is the one your caller actually feels, so always cap the whole retry sequence, not just each attempt.

Rule of thumb: perAttemptTimeout x maxAttempts should stay under your overall request budget, or you will blow your own SLA while retrying.

Retrying is dangerous if applied blindly. You must classify the failure before retrying:

• Retryable (transient): connection reset, DNS hiccup, timeout, HTTP 502/503/504, and 429 (respecting Retry-After).
• NOT retryable: 400 (bad request), 401/403 (auth), 404, 422. Retrying these just wastes load and never succeeds.
• Idempotency matters: a GET or PUT is safe to repeat; a non-idempotent POST (charge a card) can double-execute. Use an idempotency key before retrying writes.

The naive retry waits a constant delay between attempts:

• If a dependency is briefly overloaded, all your clients retry at the same fixed interval and hit it again together.
• This creates a retry storm: the very act of retrying keeps the dependency down.
• A constant short delay also wastes attempts when the outage lasts seconds, while a constant long delay wastes time on quick blips.

The fix is to grow the wait after each failure (exponential backoff) so pressure on the dependency decreases over time, and to add randomness (jitter) so clients do not synchronize. The next scenes build this up.

Exponential backoff multiplies the delay after each failed attempt, typically by a base of 2:

• delay = base * 2^attempt, e.g. with base 100ms: 100, 200, 400, 800ms.
• Always cap the delay with a maxDelay so it does not grow to minutes.
• The cap turns pure exponential growth into "capped exponential backoff", which is what you almost always want.

The intuition: a quick first retry catches one-off blips, while later attempts back off hard to give a struggling dependency room to recover.

Pure exponential backoff still has a flaw: if 1,000 clients all failed at the same instant (a shared dependency blipped), they all compute the same delay and retry at the same future moment.

• The dependency recovers, then gets hit by 1,000 simultaneous retries, and falls over again.
• This synchronized wave is the thundering herd.
• Capping the delay does not help, it just synchronizes the herd at the cap.

The cure is jitter: add randomness to each client's delay so the retries spread out across a window instead of landing on the same tick. Jitter is not optional polish, it is the part that actually protects the dependency.

The AWS-recommended strategy is full jitter: compute the capped exponential ceiling, then pick a uniformly random delay between 0 and that ceiling.

• cap = min(maxDelay, base * 2^attempt)
• delay = random(0, cap)

This spreads retries evenly across the whole window, minimizing collisions. Compared to "equal jitter" (half fixed + half random), full jitter generally yields the lowest contention and fewest total calls under load. The small cost is that an individual retry can fire very early, which is fine because the goal is to de-synchronize the herd.

Now combine bounding, classification, capped exponential backoff, and full jitter into one reusable helper. Key design points:

• Each attempt is independently bounded by a timeout.
• Only retryable errors trigger another attempt; everything else throws immediately.
• After the last attempt, rethrow so the caller can fail fast.
• An overall deadline (not shown here) should still wrap the whole loop in production.

Two production-grade refinements make the difference between a polite client and a load amplifier:

• Honor Retry-After: on 429 or 503, the server may tell you exactly how long to wait. Always prefer that value over your computed backoff, it is the dependency asking for room.
• Enforce an overall deadline: track a budget (e.g. 3s). Before sleeping, if now + delay would exceed the deadline, stop retrying and fail fast instead of blowing your SLA.

The combination keeps each retry bounded, the total bounded, and lets the dependency steer its own recovery.

Retries handle transient failures. They are the wrong tool for a sustained outage: if a dependency is hard-down, every request retrying 4 times multiplies your outbound load by 5x at the worst possible moment.

• Layer a circuit breaker above the retry helper. When failures cross a threshold, the breaker opens and short-circuits calls instantly (fail fast) instead of retrying.
• After a cool-down it goes half-open, lets a probe through, and closes again on success.
• Order of layers: breaker -> retry -> timeout. The timeout bounds each attempt, retry handles blips, the breaker stops the bleeding during real outages.

This is the full resilience stack for outbound calls in a Node.js backend.

You operate a Node.js service whose downstream payment provider briefly returns 503 during a deploy. Thousands of your instances all retry. Which single change most directly prevents your retries from re-overloading the provider the instant it recovers?

You learned how to bound and retry outbound calls without amplifying load:

• Bound everything: no outbound call without a timeout; distinguish connect, read, and total deadlines via AbortSignal.timeout.
• Classify before retrying: retry only transient, idempotent failures (timeouts, ECONNRESET, 429/502/503/504); never retry 400/401/404/422.
• Capped exponential backoff: grow the delay after each failure, but cap it with maxDelay.
• Full jitter: pick a random delay in [0, cap) to break the thundering herd. This is the part that protects the dependency.
• Respect Retry-After and a total budget: let the server steer recovery and fail fast before blowing your SLA.
• Top it with a circuit breaker: breaker -> retry -> timeout handles outages, blips, and slow calls respectively.