Retry pattern

API Design

Meaning

The retry pattern automatically re-attempts a failed operation a configurable number of times before propagating the error to the caller. It addresses the pain point of transient failures (network blips, brief service unavailability, temporary resource contention) that would otherwise break user-facing flows. Developers reach for it when an operation is idempotent or safely repeatable and the cost of failing immediately exceeds the cost of waiting and trying again.

Primary Function

Error handling

Communicative Purpose

Ensures resilience against transient failures by re-attempting operations that may succeed on a subsequent try.

Pattern

attempt operation → on transient failure → wait (with optional backoff) → retry up to max_attempts → escalate if exhausted

Core Structure

retry(operation, max_attempts, backoff)

Função primária

Error handling

Propósito comunicativo

Ensures resilience against transient failures by re-attempting operations that may succeed on a subsequent try.

Situações de gatilho

Distributed systems: calling a remote service that may experience brief outages

Contextos

Microservices, REST API clients, distributed systems, cloud SDKs, message queues, database drivers

Padrão

attempt operation → on transient failure → wait (with optional backoff) → retry up to max_attempts → escalate if exhausted

Estrutura central

retry(operation, max_attempts, backoff)

Colocados típicos

exponential backoff
jitter
circuit breaker
idempotency key
max attempts
transient error
dead letter queue

Substituições comuns

Circuit breaker (stops retries when failure rate is high)
bulkhead (isolates failures)
fallback (alternative path instead of retry)
caching (avoid the call entirely)

Erros comuns

Retrying non-idempotent operations (e.g. POST that charges a card) → duplicate side effects like double-charging

Similar / contraste

Circuit breaker: stops calling a failing service entirely instead of retrying

Interferências

Coming from synchronous scripting: may use simple try/except loops without backoff → production systems need exponential backoff with jitter

Família do chunk

exponential backoff
jitter
circuit breaker
idempotency
bulkhead
fallback

Nuance

Do not use when the operation is non-idempotent and cannot be made safe (e.g. bank transfers without idempotency keys). Performance cost grows with attempt count and backoff duration — a 5-attempt policy with exponential backoff can add 30+ seconds of latency. Boundary condition: distinguish retryable HTTP status codes (502, 503, 504, 429) from permanent ones (400, 401, 403) — retrying the latter is pointless.

Efeito pragmático

Enables systems to survive transient infrastructure failures without manual intervention, reducing user-visible errors and improving SLA compliance in distributed architectures.

Dica de memória

Like knocking on a door again after a moment when no one answered — you don't kick it down, you just try once more politely, then walk away.

Upgrade path

Circuit breaker pattern with adaptive thresholds and bulkhead isolation for multi-dependency systems

Frequência: HighFormulaicidade: FlexiblePrioridade de aquisição: Active recallPrioridade de output: BothTag de espaçamento: Medium-term

Examples

import time import random def retry(operation, max_attempts=5, base_delay=1.0): for attempt in range(1, max_attempts + 1): try: return operation() except (ConnectionError, TimeoutError) as exc: if attempt == max_attempts: raise delay = base_delay * (2 ** (attempt - 1)) delay += random.uniform(0, delay * 0.1) # jitter print(f"Attempt {attempt} failed: {exc}. Retrying in {delay:.2f}s") time.sleep(delay) def fetch_user_profile(user_id): # Simulated remote call return {"id": user_id, "name": "Alice"} profile = retry(lambda: fetch_user_profile(42))

import requests import time def fetch_with_retry(url, max_attempts=3): for attempt in range(max_attempts): response = requests.get(url, timeout=5) if response.status_code < 500 and response.status_code != 429: return response.json() if attempt < max_attempts - 1: time.sleep(2 ** attempt) response.raise_for_status() data = fetch_with_retry("https://api.example.com/metrics")

import psycopg2 import time def connect_with_retry(connection_params, max_attempts=5): last_error = None for attempt in range(max_attempts): try: connection = psycopg2.connect(**connection_params) return connection except psycopg2.OperationalError as exc: last_error = exc if attempt < max_attempts - 1: time.sleep(0.5 * (2 ** attempt)) raise last_error conn = connect_with_retry({ "host": "db.internal", "dbname": "orders", "user": "app", "password": "secret", })