Polly is a resilience framework for .NET available as a .NET Standard Library so it can run on our web services, desktop apps, mobile apps and inside our containers—anywhere .NET can run. As the name suggests, the Retry policy lets us retry a failed request due to an exception or an unexpected or bad result returned from the called code. It doesn’t wait before retrying, so we need to be careful. If the problem that caused the request to fail is not likely to resolve itself almost immediately, retrying might not help; it might even make matters worse. The Retry policy lets us define how many retries should occur before it gives up.
Polly Retry with Wait
Sometimes our application failed due to some small transient fault in the network or infrastructure we depended on, only to resolve itself just a few moments later. The Wait and Retry policy will let us pause before retrying, a great feature for scenarios where all we need is a little more time for the problem to resolve. Just like the Retry, the Wait and Retry policy can handle exceptions and bad results in called code. It also takes one extra parameter: the delay to add before each retry. The delay can be defined in a variety of ways, such as a fixed period, an array of periods or it can be a function that calculates the delay before each retry.
Polly Circuit Breaker
Let’s say if a method we’re calling or a piece of infrastructure we depend on becomes very unreliable, the best thing to do might be to stop making requests to it for a moment. The Circuit Breaker policy lets us do this. We can think of it like the circuit breaker in our home electrical system; the circuit will break, if the fault is discovered. In the same way, if a resource we depend on has a fault, we break the circuit to it.
Polly offers two implementations of the circuit breaker: the Basic Circuit Breaker, which breaks when a defined number of consecutive faults occur, and the Advanced Circuit Breaker, which breaks when a threshold of faults occur within a time period, during which a high enough volume of requests were made.
Polly Fallback Policy
Sometimes we may face a situation when request is going to fail no matter how many times we retry. The Fallback policy here will lets us return some default or perform an action like paging an admin, scaling a system or restarting a service.
Polly Cache Policy
Polly’s Cache policy lets us store the results of a previous request in memory or on distributed cache. If a duplicate request is made again, Polly will return the result from the cache rather than hitting the service a second time. This is especially useful when the requests are to remote systems. The Polly Cache supports multiple time-to-live (TTL) strategies, including relative, absolute, sliding and result. The result strategy is used in scenarios when the result of a request includes the likes of an auth token, which itself includes a TTL. The TTL from the result will determine how long the response is stored.
With some of this features, it’s no surprise that Polly is getting adopted at such a rapid pace in industry. Now that we have the knowledge of some basics down, take it for a whirl and see what a difference we can make in our own project development cycles.