1. The Problem

Your ASP.NET Core Catalog API calls a Recommendation Service to show personalized recommendations.

Normally, the flow looks like this:

User
  |
  v
Catalog API
  |
  v
Recommendation Service
  |
  v
Recommendations

One day, the Recommendation Service starts responding very slowly because its database is under heavy load.

The Catalog API keeps calling it.

Soon, requests start waiting longer, HTTP calls begin timing out, and more requests pile up waiting for the same unhealthy dependency.

The problem is no longer limited to the Recommendation Service. The failure is starting to affect the Catalog API itself.

---

2. What's Actually Going Wrong?

The Catalog API doesn't know when to stop calling a dependency that is repeatedly failing.

For example:

Request 1 --> Recommendation Service --> Timeout
Request 2 --> Recommendation Service --> Timeout
Request 3 --> Recommendation Service --> Timeout
Request 4 --> Recommendation Service --> Timeout
Request 5 --> Recommendation Service --> Timeout
                ...

Each failed call still consumes resources:

• HTTP connections
• Threads/tasks waiting for responses
• Memory
• CPU
• Request capacity

If the caller also retries every failure, the situation can become even worse.

A failing dependency can therefore cause a failure cascade into otherwise healthy services.

---

3. The Concept

A Circuit Breaker temporarily stops calls to a dependency when repeated failures indicate that the dependency is unhealthy.

Instead of continuously doing this:

Catalog API
    |
    +----> Recommendation Service (fails)
    +----> Recommendation Service (fails)
    +----> Recommendation Service (fails)
    +----> Recommendation Service (fails)
    +----> Recommendation Service (fails)

the Circuit Breaker says:

“This dependency is failing repeatedly. Stop sending requests for a while.”

The circuit has three important states.

Closed

Everything is working normally.

Catalog API
    |
    v
Circuit Breaker
    |
    v
Recommendation Service

Requests are allowed through.

Open

The failure threshold has been reached. The Circuit Breaker opens and blocks calls for a configured period.

Catalog API
    |
    v
Circuit Breaker
    |
    X
Recommendation Service

The request can fail fast or use a fallback instead of waiting for another timeout.

Half-Open

After the break period, the Circuit Breaker allows a limited test request.

Catalog API
    |
    v
Circuit Breaker
    |
    v
Recommendation Service

If the dependency has recovered:

Half-Open
    |
    | success
    v
Closed

If it is still failing:

Half-Open
    |
    | failure
    v
Open

The circuit remains open and waits before testing again.

---

4. How Do You Fix It?

Put a Circuit Breaker around the outbound call from the Catalog API.

Catalog API
     |
     v
  HttpClient
     |
     v
.NET HTTP Resilience
  - Timeout
  - Retry
  - Circuit Breaker
     |
     v
Recommendation Service

In modern ASP.NET Core applications, the .NET resilience stack can provide these capabilities around HttpClient.

Common technologies include:

• HttpClient
• Microsoft.Extensions.Http.Resilience
• Polly-based resilience capabilities

The important part is not the library. The important part is the behavior:

Repeated failures
       |
       v
Circuit opens
       |
       v
Calls fail fast
       |
       v
Dependency gets time to recover
       |
       v
Limited test
       |
       +---- Success ---> Closed
       |
       +---- Failure ---> Open

---

5. Retry vs Circuit Breaker

These two are often used together, but they solve different problems.

Retry

“This failure might be temporary. Try again.”

Call
 |
 X
 |
 Retry
 |
 v
Call again

Circuit Breaker

“This dependency is failing repeatedly. Stop calling it for now.”

Repeated failures
       |
       v
Stop calls
       |
       v
Wait
       |
       v
Test recovery

Retry helps with temporary failures. Circuit Breaker protects your application from continuously calling an unhealthy dependency.

Using retries without considering Circuit Breaker behavior can actually increase load on an already struggling service.

---

6. What Happens If You Configure It Poorly?

Circuit Breaker configuration matters.

Threshold too low

The circuit may open because of a small number of unrelated or temporary failures.

Threshold too high

The application may continue hammering an unhealthy dependency for too long.

Break duration too short

The dependency may not have enough time to recover before traffic starts again.

No timeout

A Circuit Breaker cannot protect you effectively if individual calls can wait indefinitely.

Aggressive retries

Retries can create additional traffic against an already unhealthy dependency.

The resilience strategy needs to consider timeout, retry, and Circuit Breaker together.

---

7. When Should You Use It?

Circuit Breaker is particularly useful when your application depends on another component that can become temporarily unavailable or unhealthy.

Common examples:

• ASP.NET Core API calling another microservice
• Calling an external payment or shipping provider
• Calling a recommendation or search service
• Calling an external REST API
• Accessing a remote service over HTTP
• Calling a dependency that can become overloaded

It is especially valuable when waiting for the dependency can consume significant application resources.

---

8. Visualize It in Everyday Terms

Think about an electrical circuit breaker in your house.

Normally:

Power
  |
  v
Circuit Breaker
  |
  v
Appliances

Everything works normally.

But if there is a dangerous electrical problem, the breaker trips:

Power
  |
  v
Circuit Breaker
  |
  X
Appliances

The breaker stops the flow instead of allowing the problem to continue causing damage.

A software Circuit Breaker works on a similar principle.

• Electrical circuit → Service-to-service call
• Appliance → Dependent service
• Electrical fault → Repeated failures
• Breaker trips → Circuit opens
• Power stops flowing → Calls are blocked
• Wait before restoring → Break duration
• Test the circuit → Half-Open state
• Circuit works again → Dependency recovered

The goal is not to make the dependency healthy. The goal is to protect your application while the dependency is unhealthy.

---

9. What Should You Remember?

Don't keep calling a dependency that is repeatedly failing.

The mental model is:

Normal
  |
  v
Closed
  |
  | repeated failures
  v
Open
  |
  | wait
  v
Half-Open
  |
  +---- success ----> Closed
  |
  +---- failure ----> Open

Also remember:

• Retry says “try again.”
• Circuit Breaker says “stop trying for now.”
• Timeout prevents calls from waiting indefinitely.
• Circuit Breaker protects your application from an unhealthy dependency.
• A fallback can provide degraded functionality when appropriate.
• Circuit Breaker does not fix the failing dependency.

---

10. .NET + Azure Context

A typical architecture might look like this:

ASP.NET Core Catalog API
          |
          v
       HttpClient
          |
          v
.NET HTTP Resilience
  - Timeout
  - Retry
  - Circuit Breaker
          |
          v
Recommendation Service
          |
          v
      Azure SQL

Relevant .NET/Azure technologies can include:

• ASP.NET Core / .NET for the Catalog API
• HttpClient for outbound HTTP calls
• Microsoft.Extensions.Http.Resilience for HTTP resilience
• Polly for resilience capabilities and policies
• Azure App Service, Azure Container Apps, or AKS for hosting
• Azure API Management, when resilience or traffic policies are also handled at the API gateway layer

The key architectural idea remains the same:

Healthy dependency
      |
      v
Allow calls

Unhealthy dependency
      |
      v
Stop calls temporarily
      |
      v
Protect the caller
      |
      v
Test recovery