Automatic retries need backoff; immediate tight retries pile onto the server

What it is

After a failure the system may ask again without pulling the person in each time. If automatic retry fires on the same beat as the failure, then again on the next failure, one incident is amplified into a synchronised hammer: every client hitting the same door that already cannot stand. Backoff pushes the next attempt away — usually longer each time, plus a little jitter — so retry is a sample of recovery, not fuel for an avalanche.

Why it happens

Transient faults (a dropped packet, a brief 503, a network handoff) are worth another try, because the channel may already be well on the next beat. Immediate tight retry assumes “faster trying means sooner well”, which looks reasonable on one machine and synchronises a crowd: ten thousand clients that failed in the same second become ten thousand retries in the same second. The server was about to breathe; the tide arrives again. Backoff breaks phase, lengthens with attempt count, and gives the other side and the network a cooling curve. Jitter stops everyone realigning on the same exponential.

Backoff also protects the local side. Main thread, radio and battery are dragged into a busy-wait by tight retry; what people see is failure chrome flashing, what is happening is the client punching itself. An interval lets failure presentation sit still while automatic retry walks a timetable in the background, rather than turning the UI into a clicker.

Where it stops holding

Idempotent reads may retry with backoff; non-idempotent writes (pay, create) may double-spend if retried automatically — need an idempotency key first, or do not auto-retry. Clear client errors in the 4xx (400, 403, 404) will not improve on retry; backoff is then a polite repeat of the error, and should stop. Interactive failures the person is watching can auto-retry once on a short gap, but the total budget needs a cap or the product feels like it is ramming in the background. Failures detected as offline will not grow a network by backing off until the heat death of the universe; listen for a network-restored event instead of spinning the interval.

Applying it

• Automatic retry uses an exponential (or at least increasing) interval plus jitter. Do not fetch again synchronously in the failure callback.
• Auto-back only codes that might be transient: timeout, 429, 502/503. Auth failure and “not found” stay out of this queue.
• Do not auto-retry a write without an idempotency key.
• How to check: hold the server on a persistent 503 and read the client timeline. A fetch every 50 ms until a cap is tight retry. After jittered backoff, requests should space out, and a cohort of clients should not realign in the same second.

Related

• Same group: I2.13.2 After several automatic retries fail, stop and hand the decision to the person · I2.13.3 Be explicit whether retry reuses the original parameters or allows the request to be edited · I2.13.4 A pattern of repeated failure suggests a systemic problem, not a flaky network blip
• Nearby: I2.08 Load failure · I3.05 Idempotency and duplicate submit · I4.03 Polling versus push
• Search terms: exponential backoff · retry storm · jittered retry