Retry with Backoff

Retry with backoff is a client strategy for transient failures: when a request fails, wait a short time and try again, then wait longer after each further failure. Most implementations add random jitter so that many clients do not all retry at the same instant.

Why it matters

Immediate, unlimited retries turn a small blip into an outage. If 1,000 clients each retry five times per second against a service that is already struggling, they multiply its load exactly when it can least cope. Backoff spreads that load out and gives the server time to recover.

Example

An exponential schedule with a base of 200 ms looks like this:

attempt 1: wait ~200 ms
attempt 2: wait ~400 ms
attempt 3: wait ~800 ms
attempt 4: wait ~1600 ms
give up after attempt 5

With "full jitter" you pick a random delay between 0 and the calculated value each time. If the server sends a Retry-After header with a 429 or 503 response, honor it instead of your own schedule.

Common mistakes

• Retrying non-idempotent requests, such as a payment POST, and creating duplicates. Retry only safe or idempotent operations, or use idempotency keys.
• Retrying permanent errors like 400 or 404, which will never succeed.
• Having no maximum attempt count or total time limit, so retries run for minutes.
• Forgetting that retries at every layer multiply: three layers with three retries each is 27 attempts.

Related

• Thundering herd
• Circuit breaker
• Jitter
• Rate limiting

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