Retry With Backoff and Jitter: A Reusable Pattern for Failed API Calls

A developer shares a retry function they reuse across projects, built to keep a single failed API call from overwhelming a backend. The article argues that naive retry loops, especially those with fixed delays, cause synchronized retry storms that prolong outages. The approach combines exponential backoff with full jitter so clients spread their retries out instead of firing together. It retries only on specific statuses like 429 and 503, respects Retry-After headers, and warns against retrying non-idempotent writes without idempotency keys. The author suggests starting with a 200ms base delay, a 30-second cap, and five attempts, then tuning based on observed failures.