Design Patterns & Practices  

How to Build Resilient .NET Applications with the Circuit Breaker Pattern and Polly

Introduction

Imagine you are trying to call a friend, but their phone is dead. If you keep redialing every ten seconds, you are just wasting your time and getting frustrated. In software, if a service is down and your application keeps trying to call it, it can waste system resources, slow down your app, and even crash your server.

The Circuit Breaker Pattern is a smart way to handle these situations. Just like the circuit breaker in your home that cuts off electricity during a power surge to prevent a fire, this pattern "trips" and stops requests to a failing service. This gives the struggling service time to recover and keeps your application running smoothly.

Real world example

In a real-world scenario, imagine an e-commerce site that relies on an external payment provider; if that provider crashes, your entire website could slow down or even break while waiting for a response. The Circuit Breaker acts as a smart safety switch that monitors these failures and automatically stops all outgoing requests once it detects a problem, keeping your site fast and responsive for other tasks like browsing products. After a short recovery period, the system automatically sends a few test requests to see if the provider is healthy again, either resuming normal operations or keeping the safety switch active to protect your server until the issue is fully resolved.

How It Works (The Three States)

The Circuit Breaker acts as a middleman between your app and the service you're calling. It has three modes:

  1. Closed (Normal): Everything is working. Requests pass through. If a few errors happen, it keeps track of them.

  2. Open (Failing): If the errors hit a limit (e.g., 5 failures in a row), the breaker "trips." It stops all calls immediately and returns an error message or "fallback" data without even trying to call the service.

  3. Half-Open (Testing): After a short wait (e.g., 30 seconds), the breaker lets a few requests through to see if the service is back online. If they succeed, the circuit closes. If they fail, it opens again.

Use Cases: When Should You Use It?

  • Third-Party APIs: When your app depends on services like Stripe for payments or Google Maps.

  • Microservices: To prevent one broken service from causing a "domino effect" that breaks your whole system.

  • Database Connectivity: If your database is under heavy load or performing maintenance.

Implementation with Polly (The Standard .NET Way)

In .NET, we use a popular library called Polly to handle this.

Step 1: Define the Policy

This code tells the app: "If the service fails 3 times, stop trying for 30 seconds."

var circuitBreakerPolicy = Policy
    .Handle<Exception>()
    .CircuitBreakerAsync(
        exceptionsAllowedBeforeBreaking: 3, 
        durationOfBreak: TimeSpan.FromSeconds(30)
    );

Step 2: Add a Fallback (The Backup Plan)

A Fallback Policy provides a "Plan B." Instead of showing an error page, you can show cached data or a friendly message.

var fallbackPolicy = Policy<string>
    .Handle<Exception>()
    .FallbackAsync("Our service is temporarily busy. Please try again later.");

// Wrap them together: Fallback will run if the Circuit is Open
var resilientStrategy = Policy.WrapAsync(fallbackPolicy, circuitBreakerPolicy);

var result = await resilientStrategy.ExecuteAsync(() => CallMyService());

Key Advantages

  • Prevents Cascading Failures: Stops a small problem in one service from breaking your entire application.

  • Fails Fast: Instead of making a user wait 30 seconds for a timeout, it tells them immediately that the service is busy.

  • Saves Resources: It stops your server from wasting memory and CPU on calls that are guaranteed to fail.

  • Self-Healing: The system automatically fixes itself once the external service is healthy again.

Conclusion

In this article, we have seen how the Circuit Breaker Pattern protects your application from unstable services. By using "Open" and "Half-Open" states along with Fallback policies, you can build .NET apps that stay responsive and professional even when things go wrong behind the scenes.

Membership not found