Software Resilience Patterns Cheat Sheet

Updated 2026-05-28

Next Topic: SOLID Principles Cheat Sheet

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. 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

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.

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.