Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

MechanismChapter III · Operations · Building block 2 of 10

Retry

Retry sends a failed call again if the error is temporary and the operation remains safely repeatable. Limitation and pause keep the additional load controllable.

By Michael Meierhoff · Meierhoff Systems

  1. BackoffDelays increase with each attempt.
  2. JitterRandom offsets spread client retries.
  3. LockstepSynchronized retries create load spikes.

Context

Why this is important

Temporary errors often disappear on their own, permanent ones do not. Whoever repeats immediately or in fixed time, often meets the service again at the same time. Growing, scattered breaks give him air. Timeout and Retry Storm.

This building block describes repetition rules for individual calls. Retry Storm considers the common burden of many clients; Idempotence protects business effects.

At a glance · Retries with increasing delay

If a call fails, the client waits with increasing backoff and retries until the limit is reached.
Shop example · Repeats over time

Compare four retry strategies

The shop loads the shopping cart again after a short connection error. It repeatedly limits and shows the stored cart status after the last attempt.

This is how you read the picture

  1. Backoff “Exponential backoff” schedules attempts at 200, 600, 1,400, and 3,000 ms.
  2. Jitter With “Backoff with jitter”, “at most simultaneous” is 1 instead of 3.
  3. Lockstep With “Retry immediately”, all three clients arrive at the same time.
Client 1
Client 2
Client 3

Time after the first failure

At most simultaneous: 3 of 3All three clients send at 20, 40, 60, and 80 ms simultaneously. The unhealthy service gets almost no breathing room.

Times illustrative

Choose a strategy to see when three clients send their four attempts and how many arrive simultaneously.

Benefits & limitations

Helps if:

  • Retries suit transient technical failures with a realistic prospect of later success.
  • Safe operations or stable duplicate detection allow controlled retries of the same operation.

Boundaries

  • Permanent failures persist after every attempt; classify them as terminal and pass them to error handling without further retries.
  • If the shop retries a payment call, P-731 may take effect twice; protect it with Idempotency and the key pay-B-1042.
  • Multiple retry layers multiply load; choose one layer and examine the interaction in Retry Storm.

In practice

  1. Define failure classes. Distinguish transient technical failures, permanent rejections and unknown outcomes. Assign each class a retry rule and an exit path. This produces consistent decisions that callers and operations teams can handle in the same way.
  2. Establish retry safety. Check whether the operation can run again without duplicate effects or whether the recipient recognises the same request. Record this precondition together with the request key. Resending then remains tied to the same business operation.
  3. Bound time and attempts. Set the maximum attempt count, backoff, jitter and shared deadline, and measure budget usage. Also define the response when the budget is exhausted. This caps additional load and waiting time.
Read the detailed explanation

Retry repeats a failed operation when the detected failure class suggests a transient problem. Before each attempt, retry safety, the remaining deadline and the maximum attempt count must align. A permanent business rejection needs different handling. For side effects, the distinction from Idempotency matters; waiting time follows the shared Timeout budget.

Backoff increases the pauses; jitter spreads attempts over time. A bounded retry budget protects the dependency and keeps total duration predictable. Retry controls whether and when to send again; it does not determine whether the recipient already executed the first attempt. Resolving that question belongs to the operation state and appropriate duplicate detection.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    When is exponential backoff the third attempt, and how many clients arrive at the same time?

    View the solution with justification

    In case of: 1.400 ms after the first error, and all three clients arrive simultaneously.

  2. ApplyingTransferred to a new situation

    Three clients retrieve the shopping cart after the same error. The tip shall be of 3 on 1 decrease. What strategy do you choose?

    View the solution with justification

    Backoff with jitter. The random factors between 0,5 and 1,0 distribute the experiments so that at most one arrives at the same time.

  3. EvaluateWeighing an alternative

    The team proposal is: exponential backoff without jitter is enough. What speaks for it, what speaks against it, what do you recommend?

    View the solution with justification

    For this: simple and predictable. On the other hand: All clients remain synchronous, the top remains at 3 It is repeated in every attempt. Recommendation: Complement jitter, limit attempts and total time, and resend only securely repeatable calls.

Explore further

These building blocks continue the thoughts of this page.

OperationsTimeoutA timeout limits waiting time. Here you learn how the caller handles the resulting state.Opening OperationsRetry StormA retry storm occurs when many retries continue to overload an already strained dependency.Opening CommunicationIdempotencyIdempotence keeps the business effect stable when the same command is repeated.Opening

References

Continue on the learning path

Next in Runtime & operations: Retry Storm.

10 Building blocks

Continue withRetry Storm