Retry logic

Prevents overwhelming a failing service by spacing out retries with increasing delays.

Network request: transient HTTP 502 errors; Database access: connection timeout spikes; Message queue: temporary broker unavailability

Web services, microservices, cloud functions, distributed systems, any client‑server code

def retry_with_backoff(operation, max_retries, base_delay, factor, jitter=0): for attempt in range(max_retries): try: return operation() except Exception: delay = base_delay * (factor ** attempt) + random.uniform(0, jitter) time.sleep(delay) raise Exception("Maximum retries exceeded")

Adaptive Backoff

operation: callable, max_retries: int ≥ 1, base_delay: float seconds, factor: float > 1, jitter: float ≥ 0, attempt: int, exception: Exception subclass, delay: float seconds

• exponential backoff
• jitter
• retry storm
• circuit breaker
• network latency
• exponential delay
• congestion control

• Fixed delay retry (simple but can cause congestion)
• exponential backoff with fixed factor (less responsive)
• random jitter added to backoff (reduces synchronization)
• adaptive retry based on error rates (more responsive but complex)

Using a fixed delay regardless of network conditions – cause: misunderstanding adaptivity; consequence: unnecessary delay or congestion. Applying backoff only after a fixed number of retries – cause: misinterpreting adaptation as periodic; consequence: delayed recovery when early failures are transient. Setting maximum backoff too low – cause: underestimating worst‑case latency; consequence: persistent retries and resource exhaustion. Forgetting to add jitter – cause: deterministic backoff leading to synchronized retries; consequence: retry storms and increased load. Using overly aggressive increase factors – cause: over‑reacting to transient spikes; consequence: excessively long delays that hurt user experience.

Exponential backoff – uses a fixed multiplier; Adaptive backoff – varies multiplier based on feedback. Jitter – adds randomness to delay; Adaptive backoff – may incorporate jitter but focuses on condition‑based scaling. Circuit breaker – stops retries after a threshold; Adaptive backoff – continues retrying with adjusted delay.

Coming from Python: may assume time.sleep() blocks the thread and forget to use async sleep → use asyncio.sleep or non‑blocking timers; Coming from Go: may rely on time.After without context cancellation → attach context to timers to allow early cancellation.

• Exponential backoff
• Jitter
• Circuit breaker
• Retry storm
• Rate limiting

Do not use adaptive backoff when the failure is deterministic and retrying will never succeed (e.g., invalid request); performance impact includes extra CPU for monitoring metrics and slightly longer tail latency when conditions worsen; boundary condition: when measured metrics stall (e.g., zero retries), the algorithm should fall back to a safe minimum backoff to avoid zero‑delay spikes.

Reduces network congestion and retry storms, improves overall system throughput and user‑experience by backing off intelligently rather than blindly retrying.

Think of a busy restaurant host who watches the line and tells arriving guests to wait longer only when the kitchen is backed up, but seats them quickly when it clears – the host adapts the wait time to the current load.

Adaptive backoff often combines exponential increase with jitter and a ceiling; metrics such as recent RTT or error rate are commonly used to compute the scaling factor.

Exponential backoff with full jitter and circuit‑breaker integration