서킷 브레이커가 Open 상태일 때 컨트롤러에 대한 요청의 처리 여부

1. HTTP 요청 처리 흐름

a) 정상 상태(Closed)

클라이언트 → 컨트롤러 → 서비스 → 외부 API 호출 → 응답 반환

• 모든 요청이 컨트롤러를 통해 서비스 로직까지 정상적으로 전달된다.

b) Open 상태 (Resilience4J)

클라이언트 → 컨트롤러 → 서킷 브레이커(Open) → Fallback 응답 즉시 반환 (외부 API 호출 미발생)

• 요청은 컨트롤러 엔드포인트에 도달하지만, 서킷 브레이커가 실제 비즈니스 로직 실행을 차단한다.
• 외부 API 호출 없이 Fallback 메서드에서 직접 응답 생성 (예: 503 에러)

2. 컨트롤러 계층 영향 분석

구분	요청 도달 여부	외부 API 호출 여부
Closed	✅	✅
Open	✅	❌
Half-Open	✅	⚠️ (제한적 허용)

• 컨트롤러 진입 로그: 요청은 항상 기록됨 (HTTP 요청 자체는 수신)
• 실제 처리 로직: Open 상태에서는 실행되지 않음

3. 구체적인 구현 사례( Resilience4J + Spring Boot )

@CircuitBreaker(name = "api", fallbackMethod = "fallback")
@GetMapping("/data")
public ResponseEntity<?> getData() {
    // Open 상태 시 해당 코드 블록 실행되지 않음
    return externalApi.call();
}

public ResponseEntity<?> fallback(CallNotPermittedException ex) {
    return ResponseEntity.status(503).body("서비스 중단");
}

• 컨트롤러 메서드 진입: ✅
• 비즈니스 로직 실행: ❌

4. 모니터링 지표

• Open 상태 요청 특성:HTTP 상태 코드: 503 (Service Unavailable)
• 응답 생성 주체: 클라이언트 측 Fallback 메서드
• 서비스 제공자 로그: 호출 기록 없음
• 컨트롤러 접근 확인 방법 : 엑츄에이터 엔드포인트(/actuator/circuitbreakerevents)에서 모든 서킷브레이커 이벤트 확인 

5. 결론

요청은 컨트롤러 엔드포인트에 도달하지만, Open 상태에서는 실제 비즈니스 로직(외부 API 호출)이 차단된다. 이는 서킷 브레이커가 컨트롤러 메서드 실행을 중간에 가로채기 때문이다. 따라서 시스템 부하 측면에서 HTTP 요청 수신 자체는 발생하나, 실제 리소스 소모는 Fallback 응답 생성 수준으로 제한된다.