Circuit Breaker ⚡ — Preventing Cascading Failures

A Circuit Breaker prevents an application from repeatedly calling a failing or unavailable downstream service.

flowchart LR
    A["Service A"] --> CB["Circuit Breaker"]
    CB --> B["Service B"]

    B --> X["Failure"]

    CB --> F["Fast Failure / Fallback"]

1. Why Do We Need Circuit Breaker?

Suppose Service A continuously calls Service B, but Service B is down. Without protection, Service A may keep waiting for timeouts and consume threads, connections, and other resources.

flowchart LR
    A["Service A"] --> B["Failing Service B"]
    B --> X["Timeout"]

    A --> R1["Waiting Request 1"]
    A --> R2["Waiting Request 2"]
    A --> R3["Waiting Request 3"]

This can contribute to a cascading failure across the system.

2. Circuit Breaker States

A circuit breaker commonly has three states:

• Closed — requests are allowed normally.
• Open — calls are blocked because failures exceeded a threshold.
• Half-Open — a limited test request is allowed to check recovery.

stateDiagram-v2
    [*] --> Closed

    Closed --> Open: Failure threshold reached
    Open --> HalfOpen: Recovery timeout
    HalfOpen --> Closed: Test succeeds
    HalfOpen --> Open: Test fails

3. Closed State

Under normal conditions, requests pass through the circuit breaker.

flowchart LR
    A["Service A"] --> CB["Closed Circuit"]
    CB --> B["Service B"]
    B --> R["Success"]

4. Open State

When failures exceed the configured threshold, the circuit opens. Further calls are rejected immediately instead of repeatedly calling the failing service.

flowchart LR
    A["Service A"] --> CB["Open Circuit"]

    CB --> F["Fast Failure / Fallback"]
    CB -.X.-> B["Failing Service B"]

5. Half-Open State

After a configured waiting period, the circuit allows a limited request to determine whether the downstream service has recovered.

flowchart LR
    CB["Half-Open"] --> T["Test Request"]

    T -->|"Success"| C["Closed"]
    T -->|"Failure"| O["Open"]

6. Complete Flow

sequenceDiagram
    participant A as Service A
    participant CB as Circuit Breaker
    participant B as Service B

    A->>CB: Request
    CB->>B: Call
    B-->>CB: Failure

    A->>CB: Request
    CB->>B: Call
    B-->>CB: Failure

    Note over CB: Failure threshold reached

    A->>CB: Request
    CB-->>A: Fast Failure

    Note over CB: Wait and test recovery

    A->>CB: Test Request
    CB->>B: Call
    B-->>CB: Success

    Note over CB: Circuit closes

7. Circuit Breaker vs Retry

8. Circuit Breaker with Microservices

flowchart LR
    O["Order Service"] --> CB["Circuit Breaker"]
    CB --> P["Payment Service"]

    P --> DB["Payment DB"]

    P --> X["Failure"]

    CB --> F["Fallback / Fast Failure"]

For example, if the payment service is unavailable, the order service can stop sending repeated requests instead of allowing the failure to consume its own resources.

9. Important Configuration

• Failure threshold
• Failure rate
• Open-state duration
• Half-open test requests
• Timeout
• Fallback behavior

Important Interview Questions

• What is the Circuit Breaker pattern?
• Why do we need a circuit breaker?
• What are the three circuit breaker states?
• What happens when the circuit is Open?
• What is Half-Open state?
• Circuit Breaker vs Retry?
• How does Circuit Breaker prevent cascading failures?
• What happens if the downstream service recovers?
• Where would you implement Circuit Breaker in microservices?

Key Takeaways

• Closed → requests flow normally.
• Open → calls are blocked.
• Half-Open → test recovery.
• Circuit Breaker prevents repeated calls to failing dependencies.
• It helps prevent cascading failures.
• Retry and Circuit Breaker are complementary patterns, not replacements.

Conclusion

For interviews, remember: Failure → Open Circuit → Stop Calls → Wait → Test → Recover.