Edition 0 Updated to asp. Net core 0

Additional resources 
•
Retry pattern
https://learn.microsoft.com/azure/architecture/patterns/retry
 
•
Polly and IHttpClientFactory
https://github.com/App-vNext/Polly/wiki/Polly-and-HttpClientFactory
 
•
Polly (.NET resilience and transient-fault-handling library)
https://github.com/App-vNext/Polly
 
•
Polly: Retry with Jitter
https://github.com/App-vNext/Polly/wiki/Retry-with-jitter
 
•
Marc Brooker. Jitter: Making Things Better With Randomness
https://brooker.co.za/blog/2015/03/21/backoff.html
 
Implement the Circuit Breaker pattern 
As noted earlier, you should handle faults that might take a variable amount of time to recover from, 
as might happen when you try to connect to a remote service or resource. Handling this type of fault 
can improve the stability and resiliency of an application. 
In a distributed environment, calls to remote resources and services can fail due to transient faults, 
such as slow network connections and timeouts, or if resources are responding slowly or are 
temporarily unavailable. These faults typically correct themselves after a short time, and a robust cloud 
application should be prepared to handle them by using a strategy like the “Retry pattern”.
However, there can also be situations where faults are due to unanticipated events that might take 
much longer to fix. These faults can range in severity from a partial loss of connectivity to the 
complete failure of a service. In these situations, it might be pointless for an application to continually 
retry an operation that’s unlikely to succeed.
Instead, the application should be coded to accept that the operation has failed and handle the failure 
accordingly. 
Using Http retries carelessly could result in creating a Denial of Service (
DoS
) attack within your own 
software. As a microservice fails or performs slowly, multiple clients might repeatedly retry failed 
requests. That creates a dangerous risk of exponentially increasing traffic targeted at the failing 
service. 
Therefore, you need some kind of defense barrier so that excessive requests stop when it isn’t worth 
to keep trying. That defense barrier is precisely the circuit breaker. 
The Circuit Breaker pattern has a different purpose than the “Retry pattern”. The “Retry pattern” 
enables an application to retry an operation in the expectation that the operation will eventually 
succeed. The Circuit Breaker pa
ttern prevents an application from performing an operation that’s 
likely to fail. An application can combine these two patterns. However, the retry logic should be 
sensitive to any exception returned by the circuit breaker, and it should abandon retry attempts if the 
circuit breaker indicates that a fault is not transient. 

---

308 
CHAPTER 7 | Implement resilient applications