error-handling

Retry with exponential backoff automatically re-attempts failed requests with increasing delays between attempts. Define a retry policy specifying max attempts and backoff multiplier, wrap your HTTP call, and let the handler manage retries before surfacing the error to users.

Create a hierarchy of error types that categorizes failures—validation errors, not-found, service errors—so callers can handle each category appropriately. Structured types make recovery decisions deterministic and enable consistent logging and user messaging.

A circuit breaker monitors calls to a failing service and stops sending requests once a threshold is reached, allowing the service time to recover. It transitions between closed (normal), open (blocking), and half-open (testing) states to prevent resource exhaustion and propagation of failures downstream.

Separate internal error context from public-facing messages. Log full error details for debugging, but return only actionable, non-technical messages to users—for example, "Please try again later" instead of database stack traces.

Use fallbacks when a service is genuinely unavailable or slow and retries would waste resources. Fallbacks provide degraded but functional responses—cached data, default values, or alternate endpoints—so users experience resilience rather than timeouts.

Wrap errors at each layer, preserving the original cause while adding context relevant to that layer—request ID, operation name, user input. Error enrichment creates a chain of custody that aids debugging without losing the root cause.