Resilient API Client

Calling a remote service naively

A plain fetch trusts the network to behave. It never does.

async function getUser(id) {
  // no timeout: a hang blocks this thread forever
  const res = await fetch(`/users/${id}`);
  if (!res.ok) {
    // naive: retry immediately, forever
    return getUser(id);  // ← hammers a struggling service
  }
  return res.json();
}

Wrap the call in a stack of policies

Each policy is a layer that WRAPS the next call — the same shape as Decorator/Proxy. Order matters: the Circuit Breaker sits OUTSIDE the retries, so retries can't hide failures from it; the backoff delay itself is a swappable Strategy.

// each layer wraps the next — order matters
const resilientCall =
  fallback(cachedValue,
    breaker(
      retry(backoff(1000, 3),
        timeout(2000, callService))));

Call the service — watch each layer react

Toggle the service, then hit Call. Down calls time out, retry with backoff, then the breaker OPENS and Fallback takes over — later calls fail fast with no request sent at all.

Compose policies, don't hand-roll resilience

• Compose: timeout + retry (+ backoff + jitter) + circuit breaker + fallback + bulkhead — each solves one failure mode.
• Order deliberately: breaker outside retries, timeout innermost — so the breaker sees real outcomes, not retry noise.
• Don't hand-roll it: Polly (.NET), Resilience4j (Java), or push it into a service mesh (Envoy/Istio).
• Caution: retries need idempotency — retrying a non-idempotent write can double-charge, double-send, etc.