Retry Storm

A retry storm is a sudden flood of repeat requests produced when many clients retry failed or timed-out calls at the same moment. It adds load to a service that is already struggling, so recovery becomes harder or impossible until traffic drops.

Why it matters

Retries are meant to hide brief faults, but they multiply traffic. If a service fails for ten seconds and each of its clients retries three times, it can receive roughly four times its normal load on the way back up. Layers compound the problem: a browser retries, a gateway retries and a backend retries, so one user action may become dozens of requests.

The result is a metastable failure: the original trigger is gone, yet the system stays down because retry traffic keeps it saturated.

Example

A client library configuration that avoids a storm:

max_attempts   = 3
base_delay     = 200 ms
max_delay      = 10 s
delay          = random(0, min(max_delay, base_delay * 2^attempt))
retry_budget   = 10% of requests

The random delay (jitter) spreads clients apart, and the retry budget caps total extra load.

Common mistakes

• Retrying immediately and at fixed intervals so all clients stay synchronized.
• Retrying at every layer of the stack instead of one.
• Retrying non-idempotent requests, which can duplicate orders or payments.
• Ignoring a Retry-After header.

Related

• Retry with backoff
• Thundering herd
• Jitter
• Retry-After

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.