Exponential backoff
InfrastructureWaiting longer between each retry.
Retrying after one second, then two, then four, with a little randomness added. Prevents everyone retrying in unison and turning a struggling service into a dead one.
See also Retry, Idempotency
Idempotency
InfrastructureDoing it twice has the same effect as doing it once.
A property that makes retrying safe. Usually achieved with a key the caller sends on every attempt; the server records processed keys and returns the original result instead of repeating the work. This is what prevents double charges.
See also Retry, At-least-once, Endpoint
Rate limit
BackendA cap on how often you may call something.
A restriction on request frequency, signalled by a 429 status. Exists to keep one caller from consuming a shared service. Respect it by backing off rather than retrying immediately.
See also Status code, Retry, Exponential backoff
Retry
InfrastructureTrying again after a failure.
Reasonable for 5xx errors and network failures, pointless for 4xx. Must be paired with increasing delays and with idempotency, or it turns a lost response into a duplicate action.
See also Idempotency, Exponential backoff, Status code
Status code
BackendA three-digit verdict on a request.
The first digit is what matters: 2xx worked, 3xx moved, 4xx you asked wrong, 5xx they broke. The 4 versus 5 distinction decides whether retrying can possibly help.
See also HTTP, Retry, Rate limit