Edition 0 Updated to asp. Net core 0

Implement Circuit Breaker pattern with IHttpClientFactory and Polly 
As when implementing retries, the recommended approach for circuit breakers is to take advantage of 
proven .NET libraries like Polly and its native integration with 
IHttpClientFactory
. 
Adding a circuit breaker policy into your 
IHttpClientFactory
outgoing middleware pipeline is as 
simple as adding a single incremental piece of code to what you already have when using 
IHttpClientFactory
. 
The only addition here to the code used for HTTP call retries is the code where you add the Circuit 
Breaker policy to the list of policies to use, as shown in the following incremental code. 
// Program.cs
var
retryPolicy = 
GetRetryPolicy
(); 
var
circuitBreakerPolicy = 
GetCircuitBreakerPolicy
(); 
builder.
Services
.
AddHttpClient
() 
.
SetHandlerLifetime
(TimeSpan.
FromMinutes
(
5
))
// Sample: default lifetime is 2 
minutes
.
AddHttpMessageHandler
() 
.
AddPolicyHandler
(retryPolicy) 
.
AddPolicyHandler
(circuitBreakerPolicy); 
The 
AddPolicyHandler()
method is what adds policies to the 
HttpClient
objects you’ll use. In this 
case
, it’s adding a Polly policy for a circuit breaker.
To have a more modular approach, the Circuit Breaker Policy is defined in a separate method called 
GetCircuitBreakerPolicy()
, as shown in the following code: 
// also in Program.cs
static
IAsyncPolicy 
GetCircuitBreakerPolicy
() 
{ 
return
HttpPolicyExtensions 
.
HandleTransientHttpError
() 
.
CircuitBreakerAsync
(
5
, TimeSpan.
FromSeconds
(
30
)); 
} 
In the code example above, the circuit breaker policy is configured so it breaks or opens the circuit 
when there have been five consecutive faults when retrying the Http requests. When that happens, 
the circuit will break for 30 seconds: in that period, calls will be failed immediately by the circuit-
breaker rather than actually be placed. The policy automatically interprets 
relevant exceptions and 
HTTP status codes
 as faults. 
Circuit breakers should also be used to redirect requests to a fallback infrastructure if you had issues 
in a particular resource that’s deployed in a different environment than the client application or 
service that’s performing the HTTP call. That way, if there’s an ou
tage in the datacenter that impacts 
only your backend microservices but not your client applications, the client applications can redirect 
to the fallback services. Polly is planning a new policy to automate this 
failover policy
 scenario. 
All those features are for cases where you’re managing the failover from within the .NET code, as 
opposed to having it managed automatically for you by Azure, with location transparency. 

---

309 
CHAPTER 7 | Implement resilient applications 
From a usage point of view, when using HttpClient, there’s no need to add anything new here 
because the code is the same than when using 
HttpClient
with 
IHttpClientFactory
, as shown in 
previous sections.