Debounce
Rate limit
Throttle
Choke
Network Choke Point
Carburetor Choke Value
Industrial Fluid Choke Value
Electronics (Inductor)
Governor
Exponential Backoff / Retry
The idea behind exponential backoff is to use progressively longer waits between retries for consecutive error responses. Exponential backoff can lead to very long backoff times, because exponential functions grow quickly. You should implement a maximum delay interval and a maximum number of retries. The maximum delay interval and maximum number of retries are not necessarily fixed values. They should be set based on the operation being performed and other local factors, including network latency.
Jitter
Retries can be ineffective if all clients retry at the same time. To avoid this problem, a random amount of time before making or retrying a request is added to help prevent large bursts by spreading out the arrival rate. Most exponential backoff algorithms use jitter to prevent successive collisions.
source: https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/
Circuit breaker
The Circuit Breaker design pattern is commonly used in software development to improve system resilience and fault tolerance. Circuit breaker pattern can prevent cascading failures particularly in distributed systems. The circuit breaker pattern can be used in conjunction with other patterns, such as retry, fallback, and timeout, to enhance fault tolerance in systems.
- Closed - normal operation
- Open - returns an error immediately
- Half-open - a limited number of requests are allowed to pass and the state may change to Closed or Open depending on whether the request succeeds or fails.
source: https://en.wikipedia.org/wiki/Circuit_breaker_design_pattern
See also
- Circuit Breaker Pattern - Azure Architecture Center
- Circuit breaker pattern - AWS Prescriptive Guidance
- Polly - Circuit-Breaker
Bulkhead isolation
Limits the resources consumable by the governed actions, such that a fault 'storm' cannot cause a cascading failure also bringing down other operations.
A bulkhead is a wall within a ship which separates one compartment from another, such that damage to one compartment does not cause the whole ship to sink. Premise: One fault shouldn't bring down the whole ship!
When a process begins to fault, it can build up a large number of requests, all potentially failing slowly in parallel. If unconstrained, these can chew up ever greater resource (CPU, threads, memory, etc.) in the host, degrading capability or eventually causing outright failure.
In a variant, a faulted downstream system can lead to a 'backing up' of large numbers of requests in its consumers. If ungoverned, these 'backed-up' calls can in turn consume all resources in the consumer, leading to a cascading upstream failure.
source: https://github.com/App-vNext/Polly/wiki/Bulkhead
No comments:
Post a Comment