Resilience patterns
Resilience design patterns: retry, fallback, timeout, circuit breaker - codecentric AG Blog
Retry
Whenever we assume that an unexpected response - no response for that matter - can be fixed by sending the request again, using the retry pattern can help. It is a very simple pattern where failed request are retried a configurable number of times in case of a failure before the operation is marked as a failure
Retries can be useful in case of
- Temporary network problems such as packet loss
- Internal errors of the target service, e.g. caused by an outage of a database
- No or slow responses due to a large number of requests towards the target service
Fallback
The fallback pattern enables your service to continue the execution in case of a failed request to another service. Instead of aborting the computation because of a missing response, we fill in a fallback value.
Timeout
The timeout pattern is pretty straightforward and many HTTP clients have a default timeout configured. The goal is to avoid unbounded waiting times for responses and thus treating every request as failed where no response was received within the timeout.
Timeouts are used in almost every application to avoid requests getting stuck forever. Imagine an order placement timing out in an online shop. You cannot be sure if the order was placed successfully but the response timed out if the order creation was still in progress, or the request was never processed. If you combine the timeout with a retry, you might end up with a duplicate order. If you mark the order as failed, the customer might think the order didn’t succeed but maybe it did and they will get charged.
Circuit breaker
Bulkhead pattern
