Fallback

A fallback is not an improvised response; it is a predefined alternative action or data source explicitly coded into the system's logic. This determinism is crucial for reliability. The system knows exactly what to execute when a failure is detected, avoiding unpredictable behavior during outages.

• Examples: Returning cached data, switching to a secondary API endpoint, serving a static default response, or queuing a request for later processing.
• Contrast: This differs from retry logic, which attempts the same operation again, or a circuit breaker, which stops calls but doesn't specify an alternative action.

The primary purpose of a fallback is to enable graceful degradation. Instead of a complete system failure or a generic error page, the system provides reduced functionality or non-fresh data. This maintains user trust and operational continuity.

• Objective: Uphold core user journeys even when non-critical dependencies fail.
• Implementation: A flight booking system might show cached airline schedules if the live pricing API fails, allowing users to browse options while disabling actual booking.
• Trade-off: Accepts staleness, reduced features, or higher latency in exchange for availability.

A fallback executes based on explicit failure detection. It is not a default path but a contingency activated when monitored conditions are met. These triggers are often integrated with other resilience patterns.

• Common Triggers:
  • A circuit breaker transitioning to an "open" state.
  • A timeout expiring on a synchronous call.
  • A specific exception type being thrown (e.g., ConnectionException, 5xx HTTP status).
  • The failure of a health check on a downstream dependency.
• Precision: Effective fallbacks are triggered by well-classified errors, not all exceptions, to avoid masking novel, critical failures.

The fallback action itself must be inherently more reliable than the primary operation it is replacing. It should depend on fewer, more stable components to avoid a cascading failure.

• Design Principles:
  • No External Dependencies: Ideally uses local cache, static data, or simple logic.
  • Minimal Logic: Avoids complex computation or calls to other potentially failing services.
  • Predictable Resource Use: Does not spike CPU, memory, or I/O.
• Risk Management: A complex fallback that can itself fail defeats the purpose. The fallback path is often simpler, trading sophistication for robustness.

A fallback is rarely a standalone component; it is a key tactic within a broader fault-tolerant or resilience architecture. It works in concert with other patterns to create a layered defense against failures.

• Common Architectural Synergies:
  • With Circuit Breaker: The breaker stops the flow of requests; the fallback provides the alternative response.
  • With Bulkhead Pattern: If a failure is isolated to one bulkhead (pool), fallbacks can be activated for operations using that pool while others run normally.
  • With Retry Logic: Fallbacks are often the final step after retries are exhausted.
• Systemic View: Fallbacks are a planned "Plan B" within a system's error handling strategy.

Because fallbacks represent a deviation from normal operation, their invocation must be heavily instrumented and monitored. High fallback rates are a key operational signal of chronic dependency issues.

• Critical Telemetry:
  • Fallback Rate: The percentage of requests invoking the fallback path.
  • Trigger Correlation: Linking fallback invocations to specific downstream failures or open circuit breakers.
  • Impact Assessment: Measuring the user-experience difference (e.g., data freshness lag, feature absence) between primary and fallback paths.
• Actionable Alerts: A sustained high fallback rate should trigger alerts for engineering teams to investigate the root cause in the primary dependency, as the system is operating in a degraded state.

A software design pattern that detects failures and prevents an application from repeatedly attempting an operation that is likely to fail. It acts as a proxy for operations that can fail, monitoring for errors. When failures exceed a configured threshold, the circuit opens, and all further calls immediately fail fast. After a timeout period, it enters a half-open state to test if the underlying fault has been resolved before closing again. This pattern prevents cascading failures and allows failing services time to recover.

A system design principle where functionality is reduced in a controlled, predictable manner when a failure occurs or resources are constrained. Unlike a total crash, the system maintains core operations while non-essential features are disabled. In the context of a fallback:

• A primary AI service failure triggers a switch to a simpler, more reliable model.
• A rich UI feature might revert to a basic HTML form.
• A real-time data stream might switch to displaying cached data. The goal is to provide a degraded but acceptable user experience, aligning the system's capabilities with its available resources.

A programming technique where a failed operation is automatically re-attempted, often combined with a delay strategy to increase the chance of success. Exponential Backoff progressively increases the wait time between retries (e.g., 1s, 2s, 4s, 8s). This is critical for handling transient faults like network timeouts or temporary service unavailability. Jitter (randomized delay) is often added to prevent synchronized retry storms from multiple clients. If retries are exhausted, the system should then execute its fallback strategy, moving from transient error handling to permanent failure management.

A resilience pattern inspired by ship compartments that isolate elements of an application into pools. If one bulkhead (pool) fails, the others continue to function. This prevents a single point of failure from cascading and sinking the entire system. Implementations include:

• Thread pool isolation: Dedicating separate thread pools for different services or operations.
• Connection pool isolation: Using distinct database connection pools for different client types.
• Service instance isolation: Deploying critical and non-critical services on separate compute resources. When a failure is isolated to a bulkhead, a fallback can be activated for that specific component without affecting the overall system availability.

Proactive diagnostic mechanisms to determine service viability before sending it traffic. A Health Check is a periodic request (e.g., /health) that verifies a service's operational status (database connectivity, memory usage). Outlier Detection, used in service meshes like Istio, automatically identifies and ejects unhealthy hosts from a load balancing pool based on metrics like consecutive failures (e.g., 5xx errors) or high latency. These systems provide the failure signal that triggers a circuit breaker to open or a load balancer to reroute traffic, which in turn may activate a fallback path for requests.

Two principles for managing system overload and inevitable failures. Fail-Fast immediately reports a failure condition upon detection, avoiding wasteful consumption of resources on operations destined to fail. This rapid feedback is essential for circuit breakers to trip quickly. Load Shedding is the proactive rejection or dropping of non-critical requests when a system is under excessive load. This preserves resources (CPU, memory, connections) for core operations. Shed requests can be met with a fallback response (e.g., a static error page or a queued retry-later message) instead of allowing the system to collapse entirely.