API Gateway Circuit Breaker Interview Questions and Answers
Learn API Gateway Circuit Breaker concepts through 15 interview questions and answers. Understand Resilience4j, circuit states, failure thresholds, fallbacks, retries, timeouts, bulkheads, monitoring, and Spring Cloud Gateway integration.
Introduction
In a microservices architecture, an API Gateway communicates with multiple downstream services such as User Service, Order Service, Payment Service, Inventory Service, and Notification Service.
When one downstream service becomes slow or unavailable, the gateway may continue sending requests to it. These requests can consume connections, memory, threads, and network resources until the entire platform becomes unstable.
The Circuit Breaker pattern prevents this problem by monitoring downstream calls and temporarily blocking requests when failures exceed a configured threshold.
Instead of waiting for every request to time out, the gateway fails fast and can return a fallback response. After a configured waiting period, the Circuit Breaker sends a limited number of test requests to determine whether the downstream service has recovered.
This lesson covers the 15 most important API Gateway Circuit Breaker interview questions with internal working, Spring Cloud Gateway examples, Resilience4j configuration, production use cases, common mistakes, and best practices.
What You'll Learn
After completing this guide, you'll understand:
- Circuit Breaker fundamentals
- Closed, Open, and Half-Open states
- Cascading failure prevention
- Failure and slow-call thresholds
- Count-based and time-based sliding windows
- Resilience4j integration
- Spring Cloud Gateway Circuit Breaker filters
- Fallback handling
- Retry, Timeout, and Bulkhead patterns
- Circuit Breaker monitoring and alerting
Circuit Breaker Architecture
flowchart TD
CR["Client Request"] --> GW["API Gateway"]
GW --> CB["Circuit Breaker"]
CB --> DEC{"Circuit State?"}
DEC -->|Closed - Allows Call| DS["Downstream Service"]
DEC -->|Open - Rejects Call| FR["Fallback Response\nHTTP 503"]
DS --> RESULT{"Success or Failure?"}
RESULT --> METRICS["Update Call Metrics"]
METRICS --> STATE["Change Circuit State"]
Circuit Breaker State Flow
stateDiagram-v2
[*] --> CLOSED
CLOSED --> OPEN : Failure threshold exceeded
OPEN --> HALF_OPEN : Wait duration expires
HALF_OPEN --> CLOSED : Trial calls pass
HALF_OPEN --> OPEN : Trial calls fail
1. What is the Circuit Breaker Pattern?
Answer
The Circuit Breaker pattern is a fault-tolerance mechanism that prevents an application from repeatedly calling a downstream service that is unavailable, failing, or responding too slowly.
The Circuit Breaker monitors calls made to the downstream service. When failures exceed a configured threshold, it opens the circuit and temporarily blocks additional calls.
Instead of forwarding requests to the unhealthy service, the gateway immediately returns an error or fallback response.
Example
Client
↓
API Gateway
↓
Payment Service Fails Repeatedly
↓
Circuit Breaker Opens
↓
New Requests Fail Fast
↓
Fallback Response
Benefits
- Prevents cascading failures
- Reduces unnecessary network calls
- Protects gateway resources
- Improves recovery time
- Supports graceful degradation
- Improves application availability
Interview Follow-Up
Why is a Circuit Breaker important in microservices?
Microservices depend on remote network calls. Network calls can fail, time out, or become slow. A Circuit Breaker prevents one unhealthy service from affecting the entire distributed system.
2. What Problem Does a Circuit Breaker Solve?
Answer
A Circuit Breaker primarily solves the problem of cascading failure.
When a downstream service becomes unavailable, upstream services may continue sending requests. Every request waits until a timeout occurs, consuming connections, memory, and processing capacity.
As more requests accumulate, the gateway and other services may also become unavailable.
Without Circuit Breaker
Incoming Requests
↓
API Gateway
↓
Unavailable Payment Service
↓
Requests Wait for Timeout
↓
Connections Accumulate
↓
Gateway Resources Exhausted
↓
Complete System Failure
With Circuit Breaker
Payment Failures Detected
↓
Circuit Opens
↓
Requests Fail Immediately
↓
Gateway Resources Protected
↓
Payment Service Gets Time to Recover
Problems Prevented
- Cascading failures
- Connection pool exhaustion
- Thread pool exhaustion
- Retry storms
- Increased latency
- Resource starvation
- Downstream overload
3. What are the Different Circuit Breaker States?
Answer
A Circuit Breaker normally has three states:
- Closed
- Open
- Half-Open
| State | Behavior |
|---|---|
| Closed | Requests are allowed and outcomes are monitored |
| Open | Requests are blocked and fail immediately |
| Half-Open | A limited number of trial requests are allowed |
Closed State
In the Closed state, requests flow normally to the backend service.
Request
↓
Circuit Closed
↓
Backend Service
↓
Record Success or Failure
If the failure threshold is exceeded, the circuit changes to Open.
Open State
In the Open state, requests are not forwarded to the backend.
Request
↓
Circuit Open
↓
Fallback Response
Half-Open State
After the configured waiting duration, the circuit allows a limited number of test requests.
Trial Requests
↓
Backend Healthy?
├── Yes → Circuit Closed
└── No → Circuit Open
4. How Does a Circuit Breaker Work Internally?
Answer
A Circuit Breaker records the result of every downstream call and calculates failure and slow-call rates using a sliding window.
Before forwarding a request, it checks the current circuit state.
Internal Flow
Incoming Request
↓
Check Circuit State
↓
Closed?
├── Yes
│ ↓
│ Call Backend Service
│ ↓
│ Record Result
│
├── Open
│ ↓
│ Reject Request Immediately
│
└── Half-Open
↓
Allow Limited Trial Calls
Step-by-Step Working
- The API Gateway receives a request.
- The Circuit Breaker checks its current state.
- If the circuit is Closed, the request is forwarded.
- The call result and response time are recorded.
- Failure and slow-call percentages are calculated.
- If the threshold is exceeded, the circuit opens.
- Open-state requests are rejected immediately.
- After the waiting duration, the circuit moves to Half-Open.
- A limited number of trial requests are allowed.
- Successful trial calls close the circuit.
- Failed trial calls reopen the circuit.
5. What is a Failure Rate Threshold?
Answer
The failure rate threshold defines the percentage of failed calls required to open the Circuit Breaker.
For example, assume the following configuration:
Minimum Number of Calls = 20
Failure Rate Threshold = 50%
If 12 out of 20 calls fail:
Failure Rate = 12 / 20 × 100
Failure Rate = 60%
Because the failure rate exceeds 50%, the circuit opens.
Important Parameters
| Parameter | Description |
|---|---|
| Failure Rate Threshold | Failed-call percentage that opens the circuit |
| Minimum Number of Calls | Minimum calls required before evaluating failure rate |
| Sliding Window Size | Number or duration of calls evaluated |
| Wait Duration | Time the circuit remains Open |
| Half-Open Calls | Trial calls allowed during recovery |
Interview Follow-Up
Why is the minimum number of calls important?
Without a minimum call count, one or two initial failures could open the circuit even though there is not enough traffic to determine whether the service is actually unhealthy.
6. What is a Slow-Call Threshold?
Answer
A slow-call threshold allows a Circuit Breaker to treat excessively slow responses as unhealthy calls.
A downstream service does not need to return an error to cause a problem. It may return HTTP 200 but take 20 seconds to respond. These slow calls can still exhaust gateway resources.
Example
Slow Call Duration Threshold = 2 Seconds
Slow Call Rate Threshold = 50%
Total Calls = 20
Calls Taking More Than 2 Seconds = 12
Slow Call Rate = 60%
↓
Circuit Opens
Why Slow Calls Matter
- Consume connections for longer periods
- Increase client response time
- Reduce gateway throughput
- Cause thread or event-loop congestion
- May indicate downstream overload
Best Practice
Configure both failure-rate and slow-call-rate thresholds.
7. What is a Sliding Window in a Circuit Breaker?
Answer
A sliding window stores recent call outcomes used to calculate the failure rate and slow-call rate.
Resilience4j supports two main sliding-window types:
- Count-based sliding window
- Time-based sliding window
Count-Based Sliding Window
A count-based window evaluates the most recent number of calls.
Sliding Window Size = 10 Calls
Results:
S S F F S F F F S F
Successes = 4
Failures = 6
Failure Rate = 60%
Time-Based Sliding Window
A time-based window evaluates all calls made during a recent time interval.
Sliding Window Duration = 60 Seconds
↓
Evaluate Calls Received During
the Previous 60 Seconds
Comparison
| Count-Based | Time-Based |
|---|---|
| Evaluates a fixed number of calls | Evaluates calls within a time period |
| Useful for stable request volumes | Useful for variable traffic |
| Easy to reason about | Better reflects recent time-based behavior |
8. What is Resilience4j?
Answer
Resilience4j is a lightweight fault-tolerance library designed for Java and Spring Boot applications.
It provides reusable resilience patterns for distributed systems.
Resilience4j Modules
- Circuit Breaker
- Retry
- Rate Limiter
- Bulkhead
- Time Limiter
- Cache
Advantages
- Lightweight design
- Spring Boot integration
- Reactive programming support
- Micrometer metrics
- Flexible configuration
- Functional programming support
- Independent resilience modules
Maven Dependency
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>
spring-cloud-starter-circuitbreaker-reactor-resilience4j
</artifactId>
</dependency>
Interview Follow-Up
What replaced Netflix Hystrix in modern Spring Boot applications?
Resilience4j is commonly used as the modern replacement for Netflix Hystrix, which is no longer actively developed.
9. How Do You Configure a Circuit Breaker in Spring Cloud Gateway?
Answer
Spring Cloud Gateway provides a CircuitBreaker gateway filter. The filter wraps calls to a downstream route and invokes a fallback when the Circuit Breaker opens or the call fails.
Gateway Configuration
spring:
cloud:
gateway:
routes:
- id: payment-service
uri: lb://PAYMENT-SERVICE
predicates:
- Path=/payments/**
filters:
- name: CircuitBreaker
args:
name: paymentCircuitBreaker
fallbackUri: forward:/fallback/payments
How It Works
GET /payments/100
↓
Spring Cloud Gateway
↓
paymentCircuitBreaker
↓
Payment Service
├── Success → Return Payment Response
└── Failure → Execute Fallback
Java Route Configuration
package com.codewithvenu.gateway.config;
import org.springframework.cloud.gateway.route.RouteLocator;
import org.springframework.cloud.gateway.route.builder.RouteLocatorBuilder;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
public class GatewayRouteConfiguration {
@Bean
RouteLocator gatewayRoutes(RouteLocatorBuilder builder) {
return builder.routes()
.route("payment-service", route -> route
.path("/payments/**")
.filters(filters -> filters
.circuitBreaker(config -> config
.setName("paymentCircuitBreaker")
.setFallbackUri(
"forward:/fallback/payments"
)))
.uri("lb://PAYMENT-SERVICE"))
.build();
}
}
10. What is a Fallback Response?
Answer
A fallback response is an alternate response returned when the downstream service cannot process the request.
The fallback may be executed when:
- The service is unavailable
- The call times out
- The Circuit Breaker is Open
- The downstream service returns a configured error status
- The gateway cannot establish a connection
Fallback Controller
package com.codewithvenu.gateway.controller;
import java.time.Instant;
import java.util.LinkedHashMap;
import java.util.Map;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class GatewayFallbackController {
@GetMapping("/fallback/payments")
public ResponseEntity<Map<String, Object>> paymentFallback() {
Map<String, Object> response = new LinkedHashMap<>();
response.put(
"status",
HttpStatus.SERVICE_UNAVAILABLE.value()
);
response.put(
"error",
"PAYMENT_SERVICE_UNAVAILABLE"
);
response.put(
"message",
"Payment service is temporarily unavailable. "
+ "Please try again later."
);
response.put(
"timestamp",
Instant.now().toString()
);
return ResponseEntity
.status(HttpStatus.SERVICE_UNAVAILABLE)
.body(response);
}
}
Example Response
{
"status": 503,
"error": "PAYMENT_SERVICE_UNAVAILABLE",
"message": "Payment service is temporarily unavailable. Please try again later.",
"timestamp": "2026-07-21T21:30:00Z"
}
Fallback Best Practices
- Return the correct HTTP status.
- Avoid returning false success responses.
- Do not expose internal exception details.
- Include a clear error code.
- Include a trace or correlation ID.
- Tell clients whether retrying is appropriate.
- Keep fallback logic lightweight.
11. What is the Difference Between Circuit Breaker, Retry, and Timeout?
Answer
Circuit Breaker, Retry, and Timeout are separate resilience mechanisms that solve different problems.
| Mechanism | Purpose |
|---|---|
| Timeout | Stops waiting after a configured duration |
| Retry | Repeats a failed operation |
| Circuit Breaker | Stops calls to an unhealthy dependency |
| Fallback | Provides an alternate response |
| Bulkhead | Isolates resources between dependencies |
Timeout Example
Maximum Wait Time = 2 Seconds
↓
No Response Within 2 Seconds
↓
Terminate Call
Retry Example
First Call Fails
↓
Wait
↓
Retry Call
↓
Return Result
Circuit Breaker Example
Repeated Failures Detected
↓
Circuit Opens
↓
Future Calls Fail Immediately
Important Warning
Retries should not be applied blindly.
Automatically retrying a non-idempotent operation, such as creating a payment, may create duplicate transactions.
Interview Follow-Up
Can a Circuit Breaker replace a timeout?
No. A Circuit Breaker monitors call outcomes, while a timeout limits how long an individual request is allowed to wait. Production systems normally use both.
12. What is the Bulkhead Pattern?
Answer
The Bulkhead pattern isolates resources allocated to different services or workloads.
The name comes from ships, where separate compartments prevent one leak from sinking the entire vessel.
If one downstream service becomes overloaded, its allocated resources are exhausted without affecting resources reserved for other services.
Architecture
API Gateway
│
┌────────────┼────────────┐
▼ ▼ ▼
Payment Pool Order Pool Profile Pool
│ │ │
▼ ▼ ▼
Payment Service Order Service Profile Service
Bulkhead Types
- Semaphore Bulkhead
- Thread Pool Bulkhead
- Connection Pool Isolation
- Queue Isolation
Circuit Breaker vs Bulkhead
| Circuit Breaker | Bulkhead |
|---|---|
| Stops calls to an unhealthy service | Isolates resource capacity |
| Uses call failures and latency | Uses concurrency limits |
| Protects caller and downstream | Protects unrelated workloads |
| Changes between states | Limits resource consumption |
Enterprise Example
The Payment Service is allocated a maximum of 50 concurrent calls. Even when all 50 calls are occupied, Order and Profile requests continue using their own isolated capacity.
13. How is a Circuit Breaker Used in Enterprise Applications?
Answer
Circuit Breakers are commonly applied around external or downstream dependencies such as:
- Payment processors
- Credit bureaus
- Claims systems
- Inventory services
- Third-party partner APIs
- Notification services
- Identity providers
- Legacy systems
E-Commerce Example
Client
↓
API Gateway
↓
Order Service
↓
Inventory Service
↓
Payment Service
↓
Notification Service
Suppose the Payment Service becomes unavailable.
Without Circuit Breaker
Checkout Requests Continue
↓
Payment Calls Wait for Timeout
↓
Gateway Connections Accumulate
↓
Checkout Becomes Unavailable
↓
Other Gateway Routes Are Affected
With Circuit Breaker
Payment Failures Detected
↓
Payment Circuit Opens
↓
New Payment Calls Fail Fast
↓
Fallback Returned
↓
Other Gateway Routes Continue Working
↓
Payment Service Gets Time to Recover
Enterprise Benefits
- Graceful degradation
- Faster failure responses
- Improved resource protection
- Better system recovery
- Reduced downstream load
- Partial application availability
- Improved customer experience
14. What are Common Circuit Breaker Mistakes?
Answer
Common Circuit Breaker mistakes include poor threshold selection, missing timeouts, unsafe retries, and misleading fallback behavior.
Mistake 1: One Configuration for Every Service
Different services have different latency, traffic, and reliability requirements.
A payment service should not necessarily use the same thresholds as a notification service.
Mistake 2: Very Low Failure Threshold
A few temporary failures may open the circuit unnecessarily.
Mistake 3: Very High Failure Threshold
The gateway may continue calling an unhealthy service for too long.
Mistake 4: Missing Timeout
A Circuit Breaker does not guarantee that individual calls will stop waiting within an acceptable duration.
Mistake 5: Retrying Non-Idempotent Requests
Retries may create duplicate payments, orders, or profile updates.
Mistake 6: Returning HTTP 200 from the Fallback
A successful status code may incorrectly tell clients that the business operation completed.
Mistake 7: Ignoring Slow Calls
A backend may return successful responses but respond too slowly for production requirements.
Mistake 8: Sharing One Circuit Across Unrelated Services
A failure in one downstream service could incorrectly affect another service.
Mistake 9: Missing Monitoring
Operations teams may not know circuits are opening frequently.
Mistake 10: Using Circuit Breakers as a Permanent Fix
A Circuit Breaker limits the impact of failures but does not fix the underlying service problem.
15. What are Circuit Breaker Best Practices?
Answer
A production-grade Circuit Breaker implementation should combine appropriate thresholds, timeouts, monitoring, fallback handling, and dependency isolation.
Best Practices
- Configure a separate Circuit Breaker for every downstream dependency.
- Set strict connection and response timeouts.
- Monitor failures and slow calls.
- Configure realistic minimum call counts.
- Tune thresholds using production traffic data.
- Retry only transient and idempotent operations.
- Use exponential backoff and jitter for retries.
- Return meaningful fallback responses.
- Use HTTP 503 when a required dependency is unavailable.
- Include trace IDs in error responses.
- Use Bulkheads to isolate resources.
- Monitor circuit state transitions.
- Alert when circuits remain Open for extended periods.
- Test failures using chaos engineering.
- Fix underlying service problems rather than relying only on resilience patterns.
Complete Resilience4j Configuration
server:
port: 8080
spring:
application:
name: api-gateway
cloud:
gateway:
routes:
- id: payment-service
uri: lb://PAYMENT-SERVICE
predicates:
- Path=/payments/**
filters:
- name: CircuitBreaker
args:
name: paymentCircuitBreaker
fallbackUri: forward:/fallback/payments
statusCodes:
- 500
- 502
- 503
- 504
resilience4j:
circuitbreaker:
instances:
paymentCircuitBreaker:
register-health-indicator: true
sliding-window-type: COUNT_BASED
sliding-window-size: 20
minimum-number-of-calls: 10
failure-rate-threshold: 50
slow-call-rate-threshold: 50
slow-call-duration-threshold: 2s
wait-duration-in-open-state: 30s
permitted-number-of-calls-in-half-open-state: 5
automatic-transition-from-open-to-half-open-enabled: true
management:
endpoints:
web:
exposure:
include:
- health
- metrics
- prometheus
- circuitbreakers
- circuitbreakerevents
endpoint:
health:
show-details: always
Configuration Explanation
| Property | Description |
|---|---|
sliding-window-type |
Selects count-based or time-based evaluation |
sliding-window-size |
Defines the number or duration of calls evaluated |
minimum-number-of-calls |
Minimum calls required before calculating rates |
failure-rate-threshold |
Failure percentage that opens the circuit |
slow-call-rate-threshold |
Slow-call percentage that opens the circuit |
slow-call-duration-threshold |
Duration after which a call is considered slow |
wait-duration-in-open-state |
Time the circuit remains Open |
permitted-number-of-calls-in-half-open-state |
Number of trial calls allowed |
automatic-transition-from-open-to-half-open-enabled |
Enables automatic recovery testing |
Testing the Circuit Breaker
Step 1: Start the Services
API Gateway
Payment Service
Service Registry
Step 2: Call the Payment Endpoint
curl http://localhost:8080/payments/100
Expected response:
{
"paymentId": 100,
"status": "COMPLETED"
}
Step 3: Stop the Payment Service
Call the endpoint repeatedly.
curl http://localhost:8080/payments/100
The gateway records the failures.
Step 4: Verify Open State
After the failure threshold is exceeded:
Circuit Closed
↓
Failure Threshold Exceeded
↓
Circuit Open
↓
Requests Fail Immediately
Step 5: Verify the Fallback
{
"status": 503,
"error": "PAYMENT_SERVICE_UNAVAILABLE",
"message": "Payment service is temporarily unavailable. Please try again later."
}
Step 6: Restart the Payment Service
After the configured waiting period:
Open
↓
Half-Open
↓
Trial Calls
↓
Successful Responses
↓
Closed
Monitoring Circuit Breakers
Circuit Breakers can be monitored using:
- Spring Boot Actuator
- Micrometer
- Prometheus
- Grafana
- OpenTelemetry
- Datadog
- Dynatrace
- New Relic
Important Metrics
| Metric | Purpose |
|---|---|
| Circuit State | Shows Closed, Open, or Half-Open |
| Successful Calls | Tracks completed calls |
| Failed Calls | Tracks backend failures |
| Slow Calls | Tracks calls above the latency threshold |
| Rejected Calls | Tracks calls blocked by an Open circuit |
| Failure Rate | Shows failure percentage |
| Slow-Call Rate | Shows slow-call percentage |
| Fallback Count | Tracks fallback executions |
| State Transitions | Tracks circuit state changes |
| Downstream Latency | Measures dependency response time |
Prometheus Metric Examples
resilience4j_circuitbreaker_state
resilience4j_circuitbreaker_calls_seconds_count
resilience4j_circuitbreaker_calls_seconds_sum
resilience4j_circuitbreaker_failure_rate
resilience4j_circuitbreaker_slow_call_rate
Recommended Alerts
Circuit Open for More Than 5 Minutes
Failure Rate Greater Than 50%
Fallback Count Increasing Rapidly
Downstream P95 Latency Above SLA
Multiple Circuit Breakers Opening Together
Circuit Breaker Summary
| Concept | Description |
|---|---|
| Circuit Breaker | Stops calls to unhealthy dependencies |
| Closed | Allows normal calls |
| Open | Rejects calls immediately |
| Half-Open | Allows limited recovery calls |
| Failure Threshold | Failure percentage that opens the circuit |
| Slow-Call Threshold | Slow-call percentage that opens the circuit |
| Sliding Window | Recent calls used for evaluation |
| Resilience4j | Java resilience library |
| Fallback | Alternate failure response |
| Timeout | Maximum time allowed for one call |
| Retry | Repeats a failed operation |
| Bulkhead | Isolates service resources |
| Fail Fast | Rejects calls without waiting |
| HTTP 503 | Standard Service Unavailable response |
| Actuator | Exposes health and metrics |
Interview Tips
- Start by explaining cascading failures.
- Describe Closed, Open, and Half-Open states.
- Explain failure and slow-call thresholds.
- Discuss count-based and time-based sliding windows.
- Explain why minimum call count is required.
- Differentiate Circuit Breaker, Retry, Timeout, and Bulkhead.
- Mention the danger of retrying non-idempotent operations.
- Explain Spring Cloud Gateway's
CircuitBreakerfilter. - Discuss Resilience4j configuration properties.
- Explain fallback design and correct HTTP status codes.
- Mention slow-call monitoring.
- Describe Prometheus and Grafana metrics.
- Explain why every dependency needs a separate circuit.
- Use a Payment Service or Claims Service production example.
- Discuss failure injection and chaos testing.
Key Takeaways
- A Circuit Breaker prevents repeated calls to unavailable or slow services.
- It protects API Gateway resources and prevents cascading failures.
- A Circuit Breaker operates in Closed, Open, and Half-Open states.
- Failure and slow-call thresholds determine when the circuit opens.
- Sliding windows evaluate recent service behavior.
- Resilience4j is commonly used for fault tolerance in Spring Boot applications.
- Spring Cloud Gateway provides a Circuit Breaker filter for protecting routes.
- Fallback responses support graceful degradation.
- Timeouts, retries, Circuit Breakers, and Bulkheads solve different resilience problems.
- Retries should be limited to safe and idempotent operations.
- Every downstream dependency should have its own Circuit Breaker.
- Monitoring failure rates, fallback executions, latency, and state transitions is essential.
- Production thresholds should be tuned using real traffic and latency data.
- Circuit Breakers reduce the impact of failures but do not fix the underlying service.
- Circuit Breaker knowledge is essential for Java, Spring Boot, Microservices, Cloud, DevOps, System Design, and Solution Architect interviews.