DEV Community

Nikhil Kamani
Nikhil Kamani

Posted on

Circuit Breakers Come Up In Almost Every Microservices Interview — Here's The 3-State Flow

#java #springboot #microservices #interview

I have 13 years of Java experience and have interviewed hundreds of developers at MNCs. "Explain circuit breaker state transitions" is one of the most common microservices questions I ask — most candidates can name the pattern but fumble the actual states.

Here they are:

1. CLOSED — Normal Operation

All requests go through to the real service. The circuit breaker silently tracks successes and failures in the background.

Moves to OPEN when: the failure rate crosses a threshold — e.g. 50% of the last 10 calls failed.

2. OPEN — Service Is Failing

Rejects ALL requests immediately. Doesn't even call the service — just returns a fallback response instantly.

Moves to HALF_OPEN when: a wait duration elapses — e.g. after 60 seconds, to give the service a chance to recover.

3. HALF_OPEN — Testing Recovery

Allows a small number of test requests through — e.g. 3 calls. Everything else still gets the fallback.

Test calls succeed → back to CLOSED. Test calls fail → back to OPEN.

Why it actually matters, not just theory:

Say Payment Service goes down.

Without a circuit breaker: 100 users each wait 30 seconds for a timeout. Threads pile up waiting on a dead service. The failure cascades into your own system.

With a circuit breaker: the first ~10 requests fail and the circuit OPENS. The next 90 requests fail instantly, no waiting. Users get "Payment down, try later" and the rest of the system stays responsive.

The code (Spring Boot + Resilience4j):

@Service
public class OrderService {

    @CircuitBreaker(name = "payment-service", fallbackMethod = "paymentFallback")
    public PaymentResult processPayment(Order order) {
        return paymentClient.charge(order.getTotal());
    }

    // Called when circuit is OPEN or the call fails
    private PaymentResult paymentFallback(Order order, Exception e) {
        return PaymentResult.failed("Try again later.");
    }
}
Enter fullscreen mode Exit fullscreen mode 
resilience4j:
  circuitbreaker:
    instances:
      payment-service:
        failure-rate-threshold: 50
        wait-duration-in-open-state: 60s
Enter fullscreen mode Exit fullscreen mode

The follow-up I always ask next: how is this different from Retry? Retry helps with transient blips — a single dropped packet, a momentary glitch. Circuit breaker helps with sustained outages — there's no point retrying against a service that's been down for 2 minutes, you're just adding load to something already struggling.

Other resilience patterns worth knowing alongside this: Timeout (gives up waiting after a max duration), Bulkhead (isolates thread pools so one failing service can't starve others), and Rate Limiter (caps requests per second to protect a service).

I cover this and more (Core Java, Java 8 to 21, Multithreading, Spring Boot, Microservices, Design Patterns, Coding Round Patterns) in my guide.

Free sample: https://drive.google.com/file/d/1u3PQbTY1gLn34UmWG7Cxx4cmdibD2dvU/view?usp=sharing

Full guide: https://kamaninikhil.gumroad.com/l/java-interview-guide

Feedback, typos, or suggestions? Email me: kamaninikhil71@gmail.com

Which state trips people up most — OPEN or HALF_OPEN? Drop it in the comments.

Top comments (0)