Node.js Retry Pattern: Handling Transient Failures with Express

When you’re calling third-party APIs from an Express controller, "it works on my machine" rarely holds up in production. Network blips happen, and upstream services go down for a few seconds. If you aren't using a node.js retry pattern, your users end up staring at 500 errors for faults that would have resolved themselves with a simple second attempt.

I spent an entire week chasing ghost errors in a distributed system until I realized we were treating every 503 error as a permanent failure. Implementing a proper retry mechanism changed our service reliability overnight.

Why Simple Retries Fail

Initially, we just wrapped our fetch calls in a for loop. It looked something like this:

JAVASCRIPT
// Don't do this!
for (let i = 0; i < 3; i++) {
  try {
    return await axios.get(url);
  } catch (err) {
    if (i === 2) throw err;
  }
}

The problem? We were hammering the failing service immediately after the first failure. If the service was struggling, our aggressive retries just made the congestion worse—a classic recipe for a cascading failure. You need exponential backoff node logic to space out your attempts.

Implementing Exponential Backoff

Instead of retrying immediately, you wait for a progressively longer duration between attempts. This gives the downstream system breathing room to recover.

Here is a utility function I use to wrap unstable async calls:

JAVASCRIPT
const wait = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

async function retry(fn, retries = 3, delay = 500) {
  try {
    return await fn();
  } catch (err) {
    if (retries <= 0 || !isTransientError(err)) throw err;
    
    console.warn(CE9178">`Retrying... attempts left: ${retries}`);
    await wait(delay);
    return retry(fn, retries - 1, delay * 2); // Exponential growth
  }
}

The isTransientError helper is critical. You only want to retry on things like 503 Service Unavailable or 429 Too Many Requests, not on 400 Bad Request or 401 Unauthorized.

Integrating with Express Middleware

To keep your controllers clean, you should handle these patterns at the middleware layer. If you've been following my previous advice on Mastering Express Async Middleware: A Guide to AsyncHandler Wrappers, you know that wrapping your routes is essential.

When you add transient fault handling to your stack, it’s best to keep the retry logic decoupled from the route handlers themselves. I prefer using a dedicated service layer that encapsulates the network calls.

Handling Async Errors Correctly

Even with retries, some requests will eventually fail. You must ensure these errors propagate correctly to your centralized error handler. If you haven't set that up yet, check out Express Error Handling: Centralized Middleware for Node.js APIs to ensure your app doesn't leak stack traces or hang indefinitely.

Proper express async error handling requires that you don't swallow errors in your retry blocks. If the retry function exhausts its attempts, it must re-throw the original error so the Express next() function can catch it.

Practical Caveats

One thing I’m still careful about: don't retry non-idempotent operations like POST requests unless you're 100% sure the server supports it or you have idempotency keys. Retrying a payment creation request because you didn't get a response could result in double-charging your customer.

I’ve also found that adding a "jitter" (a random amount of time added to the delay) prevents "thundering herd" problems where many instances of your service retry at the exact same millisecond.

Next time, I’d probably reach for a library like p-retry earlier in the project lifecycle instead of rolling my own implementation. It handles the edge cases, like abort signals and custom retry policies, that I had to manually write. For now, this custom approach works fine for our internal microservices, but keep an eye on your complexity.