The Circuit Breaker pattern acts like an electrical circuit breaker. It monitors calls to a specific service. If a certain number of calls fail within a defined time window, or if the failure rate exceeds a configured threshold, the circuit breaker transitions to the 'open' state. In this state, subsequent calls to the service are immediately rejected without even attempting to execute the underlying operation. This prevents the failing service from being overwhelmed and stops the failure from propagating to other parts of the system. After a configured timeout period, the circuit breaker enters a 'half-open' state. In this state, a limited number of test calls are allowed. If these test calls succeed, the circuit breaker transitions back to the 'closed' state, allowing normal operation. If they fail, it returns to the 'open' state. This pattern is crucial for isolating failures and allowing services to recover.

The Rate Limiter pattern is designed to control the rate at which operations can be performed. It's particularly useful for protecting services from being overwhelmed by a sudden surge of requests, whether intentional or unintentional. By setting a limit on the number of calls allowed per unit of time (e.g., requests per second), the Rate Limiter ensures that the service operates within its capacity. When the limit is reached, subsequent requests are either rejected, queued, or delayed, depending on the configuration. This helps maintain the stability and availability of the service, especially under heavy load.

The Retry pattern is employed to handle transient failures, which are temporary issues that are likely to resolve themselves. When an operation fails, the Retry mechanism automatically attempts to execute it again. This can be configured with a fixed number of retries, an exponential backoff strategy (where the delay between retries increases), or a jittered backoff (adding randomness to the delay to avoid synchronized retries). Retries are most effective when failures are intermittent and the underlying cause is expected to be short-lived. It's important to configure retries carefully to avoid overwhelming the failing service or delaying responses excessively.

The Bulkhead pattern is inspired by the watertight compartments in a ship. In software, it means partitioning resources (like thread pools or connection pools) so that a failure in one partition does not affect others. For example, if you have multiple downstream services, you might assign a separate thread pool to calls made to each service. If one service becomes slow or unresponsive, it will only consume threads from its dedicated pool, leaving the threads for other services unaffected. This prevents a failure in one part of the system from cascading and bringing down the entire application.

The Fallback pattern is a crucial component of resilience. When a primary operation cannot be completed successfully (e.g., due to a timeout, an error, or an open circuit breaker), a fallback mechanism is invoked. This fallback can be a static response, a default value, a call to a different, less critical service, or even a cached response. The goal of a fallback is to provide a graceful degradation of service, ensuring that the user experience is not completely disrupted. It allows the system to remain partially available even when dependencies are experiencing issues.