ngosangns Knowledge Base

Retry With Backoff

#technology#resilience#aws#design-patterns

Updated: 2026-09-24

This pattern improves application stability by automatically retrying operations that failed because of transient errors, while progressively increasing the wait time between attempts. Distributed systems still see network congestion, slow responses, and throttling. A tight retry loop can overload the service, so the wait grows, often from 1 second to 2, then 4, then 8. Random jitter stops clients from retrying at the same moment. The call should be idempotent, or a repeat can charge twice or corrupt data. If the error is permanent, such as a wrong password, fail fast instead of retrying.

Core Idea

In a distributed architecture, transient errors such as network congestion, slow service responses, or throttling are unavoidable. Instead of giving up immediately or retrying continuously and overloading the system, we:

  • Retry: Attempt the operation again.
  • Exponential backoff: Increase the wait time after each failure (for example, 1s, 2s, 4s, 8s...).
  • Jitter: Add a random amount of time to the backoff so that all clients do not retry at the same moment (the thundering herd effect).

When to Use

  • When the service is throttling requests (429 Too Many Requests).
  • When there are temporary network problems.
  • When the target service is temporarily unavailable but likely to recover quickly.

Considerations

  • Idempotency: The retried operation MUST be idempotent (calling it multiple times has the same result as calling it once) to avoid corrupting data (for example, charging money twice).
  • Fail fast: If you can determine that the error is not transient (for example, wrong password or wrong parameters), use a Circuit Breaker to report the failure right away instead of retrying in vain.
  • User experience: Letting the wait time grow too long can hurt users' perception of the application's speed.

Implementation on AWS

  • AWS Step Functions: Provides built-in configuration for retry with exponential backoff without writing code. You can define ErrorEquals, IntervalSeconds, MaxAttempts, and BackoffRate.
  • AWS SDKs: Most AWS software development kits (SDKs) already include a default retry mechanism for services such as DynamoDB and S3.
  • AWS Lambda: You can implement retry logic in code yourself if you need deep customization.

Example

A customer sentiment analysis system calls Amazon Comprehend:

  1. The first call fails with a 503 error (service busy).
  2. The system waits 1 second and retries.
  3. If it still fails, it waits 2 seconds (1.0 * 2.0) and retries.
  4. If it still fails, it waits 4 seconds and retries.
  5. Only after the maximum number of attempts (for example, 3) is exhausted does it report a real error or push the request to a queue for later processing.

See also: Circuit Breaker · Saga Orchestration