Resilience

Ensures continued operation when the primary resource fails

Web service: primary API endpoint returns 5xx error; Database access: primary replica is unreachable; Feature toggle: requested feature not enabled

Microservices, cloud-native applications, high-availability systems

detect failure → select fallback implementation → continue processing

• fallback handler
• fallback strategy
• default implementation

• use try‑except with a default value → simpler but less flexible
• employ circuit breaker pattern → adds proactive failure prevention at the cost of extra latency

Choosing a fallback that shares state with the primary can cause data corruption; Implementing fallback without proper logging hides root causes; Selecting a fallback that is slower than the primary negates performance benefits

circuit breaker – proactive failure prevention vs fallback – reactive handling; retry logic – repeats the same operation vs fallback – switches to an alternative

Coming from JavaScript: using the || operator for fallback may mask falsy values like 0 → prefer nullish coalescing (??) or explicit checks

• retry
• circuit_breaker
• graceful_degradation

Do not use fallback when the primary system is highly reliable and added complexity outweighs benefits; Fallback introduces extra latency due to the additional call or computation; Ensure the fallback is idempotent and does not introduce state inconsistencies

Enables service continuity during outages, reduces user‑facing errors, and simplifies error handling logic

A fallback is like a spare tire kept in the trunk, ready to replace the main tire when it blows out.

Fallback implementations should be stateless and side‑effect free to avoid cascading failures

Implement a circuit breaker pattern for proactive failure handling