Retry Logic

The simplest strategy, where retry attempts occur after a constant, predefined interval (e.g., 1 second). This is predictable but inefficient for transient faults that may require variable recovery times.

• Use Case: Simple, low-throughput operations where a brief, consistent pause is sufficient.
• Drawback: Can exacerbate load on a recovering service if all clients retry simultaneously, creating a thundering herd problem.

A core strategy where the wait time doubles (or grows exponentially) with each consecutive retry attempt (e.g., 1s, 2s, 4s, 8s). This provides increasing time for a failing downstream service to recover.

• Mechanism: Calculated as delay = base_delay * (2 ^ (attempt - 1)).
• Purpose: Dramatically reduces load on strained systems and is the standard for handling transient network or cloud service faults.
• Standard Practice: Mandatory in cloud SDKs (AWS, Azure, GCP) for API calls.

The addition of randomness to retry delays to prevent synchronized client behavior. It is almost always combined with Exponential Backoff.

• Implementation: final_delay = calculated_backoff_delay + random(0, jitter_max).
• Critical Benefit: Eliminates the thundering herd problem, where many clients retry simultaneously, causing repeated traffic spikes that prevent system recovery.
• Result: Smoothes aggregate load, increasing the overall probability of successful retries across a distributed client base.

A strategy where the delay between retries increases by a fixed, additive amount (e.g., 1s, 2s, 3s, 4s). It provides a middle ground between Fixed Delay and Exponential Backoff.

• Formula: delay = base_delay + (increment * (attempt - 1)).
• Use Case: Scenarios where exponential growth is too aggressive, but some increasing grace period is needed. Less common than exponential strategies.

A strategy that reattempts a failed operation instantly, without any delay. This is a high-risk pattern used only for specific, predictable error modes.

• Appropriate Use: Handling idempotent operations that may fail due to brief race conditions (e.g., optimistic locking conflicts) where success is likely on the next CPU cycle.
• Severe Risk: Can rapidly amplify failures and consume system resources if the underlying fault is not truly instantaneous. Must have a very low maximum attempt count (e.g., 2-3).

Advanced strategies that dynamically adjust retry behavior based on system-wide health signals, moving beyond static configurations.

• Retry Budget: A global quota limiting the total rate or percentage of requests that can be retried, preventing retries from overwhelming the system during partial outages.
• Adaptive Backoff: Algorithms that adjust base delays or jitter based on real-time metrics like observed latency or success rates from recent attempts.
• Integration: These are often implemented within service mesh sidecars (e.g., Istio, Linkerd) to provide application-agnostic resilience.

A retry strategy where the delay between consecutive retry attempts increases exponentially (e.g., 1s, 2s, 4s, 8s). This is a critical companion to retry logic, as it:

• Reduces load on a struggling service.
• Increases the probability that transient issues (network glitches, temporary resource exhaustion) resolve before the next attempt.
• Often incorporates jitter (randomized delay) to prevent synchronized retry storms from multiple clients.

A resilience pattern that isolates application resources (like thread pools, connections, or service instances) into distinct, fault-tolerant compartments. If one bulkhead fails due to excessive load or errors, the failure is contained, and other compartments continue to function. This prevents a single point of failure from sinking the entire application, analogous to watertight sections in a ship.

A predefined alternative response or action executed when a primary operation fails. A fallback provides graceful degradation, allowing the system to maintain partial functionality. Examples include:

• Returning cached or stale data.
• Providing a default or simplified response.
• Redirecting to a backup service.
• Informing the user of a temporary issue. Effective fallbacks are a key outcome of robust retry and circuit breaker logic.

A periodic diagnostic probe (e.g., an HTTP endpoint) used to verify a service's operational status. Health checks are foundational for resilience patterns:

• Circuit Breakers may use health check results to determine when to transition from Half-Open to Closed.
• Load Balancers and service meshes use them for outlier detection, removing unhealthy instances from traffic pools.
• They enable connection draining during deployments by marking an instance as unhealthy for new requests while it finishes processing existing ones.