Exponential backoff

Exponential backoff spaces retries out by doubling the delay each time — 0.5 s, 1 s, 2 s, 4 s — up to a cap, giving a struggling server room to recover. Jitter randomises each delay, because without it every client that failed at the same moment retries at the same moment, recreating the spike that caused the failure.

How it works

A typical policy: wait a random time between zero and base × 2^attempt, capped at a maximum, and give up after a fixed number of attempts or total time. Only retry what is safe to retry — idempotent methods, or writes protected by an idempotency key — and only on failures that might be transient: timeouts, 429, 502, 503, 504.

The misconception

That more retries means more reliability. Unbounded retries amplify an outage: each layer that retries three times multiplies the load on the layer below. Retry budgets, caps and circuit breakers exist because retrying is itself a source of failure.

Try it here

Configure the Fault Injection API with PUT /faults/v1/config — say a failureRate of 0.5 and status 503 — then call GET /faults/v1/target repeatedly to watch your retry policy cope with a flaky dependency.

Sources

Other terms

Retry-After — A response header telling the client how long to wait before trying again, in seconds or as a date.
Fault injection — Deliberately introducing failures — errors, latency, garbage responses — to test how a system copes.
ETag — An opaque version identifier for a representation, used to avoid re-sending it and to detect conflicting writes.
Safe and idempotent methods — Two independent properties of HTTP methods that decide what a client is allowed to retry.
PUT vs PATCH — PUT replaces a resource with the representation you send; PATCH applies a set of changes to it.
Request timeout — The maximum time a client will wait for a response before abandoning the request.

All glossary terms · Testing techniques · All 39 mock REST APIs

Last updated 16 October 2026