Software Resilience Patterns Cheat Sheet

Updated 2026-05-28

Next Topic: SOLID Principles Cheat Sheet

🧠Study flashcards on this topic146 cards · spaced repetition→

Software resilience patterns are architectural strategies designed to build fault-tolerant, self-healing systems that continue functioning despite failures, network issues, or overload conditions. In distributed systems, where failures are inevitable rather than exceptional, resilience engineering shifts from preventing failures to designing systems that gracefully handle them. These patterns—from circuit breakers that prevent cascading failures to chaos engineering that deliberately injects faults—form the foundation of modern production systems at scale. Understanding not just what each pattern does but when and why to apply it transforms fragile systems into robust, production-ready architectures that survive the chaos of real-world operations.

What This Cheat Sheet Covers

This topic spans 18 focused tables and 153 indexed concepts, 146 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Circuit Breaker States & BehaviorTable 2: Retry & Backoff StrategiesTable 3: Isolation & Resource ManagementTable 4: Timeout & Fallback PatternsTable 5: Health Monitoring & ProbesTable 6: Observability for ResilienceTable 7: Distributed Transaction PatternsTable 8: Traffic Management & Load ControlTable 9: Rate Limiting AlgorithmsTable 10: Service Mesh & Proxy PatternsTable 11: Caching for ResilienceTable 12: Deployment Resilience PatternsTable 13: Data Partitioning & ShardingTable 14: Failure Detection & PreventionTable 15: Dead Letter HandlingTable 16: Chaos EngineeringTable 17: Resilience Library ImplementationsTable 18: SRE Reliability Engineering

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Circuit Breaker States & Behavior

The circuit breaker pattern monitors calls to a downstream service and stops requests when failure rates exceed a threshold, giving the service time to recover. Mastering the state machine — including when transitions occur and what thresholds trigger them — is essential for tuning circuit breakers without causing false trips or masking real outages.

State	Example	Description
Closed (Normal)	`circuitBreaker.state = CLOSED` `request → downstream service`	• Requests flow normally to the downstream service • failure counter tracks errors against a threshold (e.g., 5 failures in 10 seconds) before opening.
Open (Failing)	`circuitBreaker.state = OPEN` `request → immediate FailFastException`	• All requests fail immediately without calling the service • protects downstream by preventing further load • transitions to half-open after a timeout period (e.g., 60 seconds).
Half-Open (Testing)	`circuitBreaker.state = HALF_OPEN` `limited test requests → service`	• Allows a limited number of test requests (e.g., 3) to check if the service recovered • success → transitions to closed • failure → transitions back to open.
Failure Threshold	`failureThreshold = 5` `errorPercentage = 50%`	• Trigger condition for opening the circuit • can be absolute count (5 failures) or percentage (50% error rate) within a sliding time window.
Slow Call Rate Threshold	`slowCallDuration = 2s` `slowCallRateThreshold = 50%`	• Circuit opens when percentage of slow calls exceeds threshold, even if calls succeed • protects downstream from load that would eventually time out • Resilience4j-specific configuration.
Timeout Period	`openTimeout = 60s`	• Duration the circuit stays open before attempting recovery • prevents premature retry attempts while the downstream service recovers.
Success Threshold	`successThreshold = 3`	• Number of consecutive successful test requests in half-open state required to transition back to closed • prevents premature closing on a single lucky success.
Metrics-Only Mode	`circuitBreaker.state = METRICS_ONLY` `requests pass through`	• Special state that records metrics without breaking the circuit • useful for monitoring and testing circuit breaker behavior without impacting traffic.
Forced-Open Mode	`manualControl.isolateAsync()` `circuitBreaker.state = FORCED_OPEN`	• Manually holds circuit open to block all calls to a downstream service • used during maintenance windows or known outages • only exits via explicit manual close.

Table 2: Retry & Backoff Strategies

Retry logic is one of the most commonly misimplemented resilience patterns — done wrong it amplifies failures instead of absorbing them. The key distinctions are which errors warrant a retry (transient vs. permanent), how long to wait between attempts (backoff), and how to prevent synchronized retry storms across clients (jitter).

Pattern	Example	Description
Exponential Backoff	`delay = baseDelay * (2 ** attempt)` `delays: 1s, 2s, 4s, 8s, 16s`	• Retry delay doubles after each failure • prevents retry storms by spreading attempts over time • AWS SDKs implement this by default in standard mode.

The rest of this section is part of the full cheat sheet

Table 3: Isolation & Resource Management

Isolation patterns limit the blast radius when a service or dependency misbehaves. The bulkhead metaphor — compartments in a ship's hull — captures the core idea: constrain failures so one sinking compartment doesn't flood the whole vessel.

Pattern	Example	Description
Bulkhead (Thread Pool)	`paymentPool: maxThreads=20` `searchPool: maxThreads=10`	• Separate thread pools per service to isolate failures • one service's exhaustion doesn't block others • named after ship compartments that prevent total flooding.

The rest of this section is part of the full cheat sheet

Table 4: Timeout & Fallback Patterns

Timeouts are the single most impactful resilience primitive — without them, a single slow downstream dependency can exhaust all threads. The critical insight is that timeouts must be layered and aligned: each layer's timeout must expire before the caller's, so errors propagate cleanly up the stack.

Pattern	Example	Description
Connection Timeout	`connectTimeout = 2s` `fails if connection takes >2s`	• Maximum time to establish initial connection • protects against unresponsive hosts • should be shorter than request timeout to allow retry attempts.

The rest of this section is part of the full cheat sheet

Table 1: Circuit Breaker States & Behavior

State	Example	Description
Closed (Normal)	`circuitBreaker.state = CLOSED` `request → downstream service`	• Requests flow normally to the downstream service • failure counter tracks errors against a threshold (e.g., 5 failures in 10 seconds) before opening.
Open (Failing)	`circuitBreaker.state = OPEN` `request → immediate FailFastException`	• All requests fail immediately without calling the service • protects downstream by preventing further load • transitions to half-open after a timeout period (e.g., 60 seconds).
Half-Open (Testing)	`circuitBreaker.state = HALF_OPEN` `limited test requests → service`	• Allows a limited number of test requests (e.g., 3) to check if the service recovered • success → transitions to closed • failure → transitions back to open.
Failure Threshold	`failureThreshold = 5` `errorPercentage = 50%`	• Trigger condition for opening the circuit • can be absolute count (5 failures) or percentage (50% error rate) within a sliding time window.
Slow Call Rate Threshold	`slowCallDuration = 2s` `slowCallRateThreshold = 50%`	• Circuit opens when percentage of slow calls exceeds threshold, even if calls succeed • protects downstream from load that would eventually time out • Resilience4j-specific configuration.
Timeout Period	`openTimeout = 60s`	• Duration the circuit stays open before attempting recovery • prevents premature retry attempts while the downstream service recovers.
Success Threshold	`successThreshold = 3`	• Number of consecutive successful test requests in half-open state required to transition back to closed • prevents premature closing on a single lucky success.
Metrics-Only Mode	`circuitBreaker.state = METRICS_ONLY` `requests pass through`	• Special state that records metrics without breaking the circuit • useful for monitoring and testing circuit breaker behavior without impacting traffic.
Forced-Open Mode	`manualControl.isolateAsync()` `circuitBreaker.state = FORCED_OPEN`	• Manually holds circuit open to block all calls to a downstream service • used during maintenance windows or known outages • only exits via explicit manual close.

Table 2: Retry & Backoff Strategies

Pattern	Example	Description
Exponential Backoff	`delay = baseDelay * (2 ** attempt)` `delays: 1s, 2s, 4s, 8s, 16s`	• Retry delay doubles after each failure • prevents retry storms by spreading attempts over time • AWS SDKs implement this by default in standard mode.

Table 3: Isolation & Resource Management

Pattern	Example	Description
Bulkhead (Thread Pool)	`paymentPool: maxThreads=20` `searchPool: maxThreads=10`	• Separate thread pools per service to isolate failures • one service's exhaustion doesn't block others • named after ship compartments that prevent total flooding.

Table 4: Timeout & Fallback Patterns

Pattern	Example	Description
Connection Timeout	`connectTimeout = 2s` `fails if connection takes >2s`	• Maximum time to establish initial connection • protects against unresponsive hosts • should be shorter than request timeout to allow retry attempts.