Skip to content
SystemSyncer
Menu

Integration concept

What Are Retry Strategies?

How integrations retry failed operations — immediate, fixed, exponential backoff, jitter, Retry-After, attempt limits, and circuit breakers — and which errors to retry.

Last reviewed:
Reading time
2 min read
By
Raúl Vaquerizo Tortosa

Short answer

A retry strategy defines when, how often, and how many times an integration repeats a failed operation. Good strategies retry only transient errors, wait progressively longer between attempts (exponential backoff), add randomness (jitter) to avoid synchronized retry storms, honor rate-limit signals such as Retry-After, and stop after a bounded number of attempts by sending the job to a dead-letter queue.

A retry strategy is the policy an integration follows when an operation fails: whether to try again, when, and when to give up. A good strategy turns brief outages into short delays; a bad one turns them into duplicate data or overloaded systems.

Which errors to retry

Retry transient failures — those likely to succeed later:

  • network errors and timeouts,
  • HTTP 429 (too many requests), 502, 503, 504,
  • platform throttling errors.

Do not retry permanent failures — they will fail again:

  • validation errors (HTTP 400, 422),
  • authentication and permission errors (401, 403),
  • not found (404), unless you expect eventual consistency.

Only retry operations that are idempotent, or made idempotent with keys or external references.

Common strategies

Strategy Behavior Suitability
Immediate retry Retry at once Only for one quick retry of a dropped connection
Fixed delay Wait the same time each attempt Simple, but retries pile up during long outages
Exponential backoff Delay doubles each attempt (2 s, 4 s, 8 s…) Standard choice; reduces load on struggling systems
Exponential backoff + jitter Randomize each delay within the exponential range Recommended; prevents synchronized retry waves
Server-directed Wait as instructed by Retry-After or throttle data Always honor when provided

Limits

Every strategy needs bounds:

  • Maximum delay between attempts (for example, 30 minutes).
  • Maximum attempts or maximum age, after which the job moves to a dead-letter queue.
  • Circuit breaker to pause all calls to a dependency that is clearly down.

Choosing parameters

Base parameters on business tolerance. If an order must reach the ERP within two hours, design the retry sequence to cover about that window before escalating. For inventory, shorter sequences are better — a stock update that is hours old may be worse than none, and the next update will supersede it.

Summary

Retry only transient errors on idempotent operations. Use exponential backoff with jitter, honor server signals, cap delays and attempts, and hand off to a dead-letter queue when attempts run out. See how to implement retries and idempotency for code.

Frequently asked questions

How many times should an integration retry?

Enough to ride out typical transient outages within your business tolerance. For order export, attempts spread over one to a few hours are common. Then stop and send the job to a dead-letter queue.

What is a circuit breaker?

A mechanism that stops calling a failing dependency for a period once failures exceed a threshold, then tests it with a few requests before resuming. It prevents every job from wasting attempts during an outage.

Should retries happen inside the request or in a queue?

For more than a couple of quick attempts, use a queue with scheduled retries. In-request retries hold resources and can exceed timeouts.

Sources and further reading

Platform-specific statements on this page were checked against these sources on . Vendor APIs change; confirm details in the current documentation before you build.

  1. [1] Exponential backoff and jitter — AWS Architecture Blog
  2. [2] RFC 9110: Retry-After header — IETF
  3. [3] Circuit breaker pattern — Martin Fowler

Related reading