왜 서킷브레이커가 필요하다고 생각했을까?

실무에서 한창 운영 중에 이벤트나 프로모션 진행 시 반복적으로 마주한 문제 상황

서비스를 운영하며 다음과 같은 위험 패턴이 자주 발생했음.

• 특정 API에서 응답 지연 또는 간헐적 장애 발생
• 요청 타임아웃으로 인해 클라이언트 NuxtSSR → Gateway → BFF → 백엔드 간의 호출 체인이 길어지고
• 비동기 대기 요청이 급증하면서 시스템 전체의 처리 능력이 급격히 하락
• 결국 페이지 로딩 실패, 사용자 이탈, 서버 과부하로 이어지는 구조적 리스크로 확장.

일시적 장애 하나로도 전체가 영향을 받는 구조

이러한 상황은 단순한 일회성 에러라기보다,

“작은 실패가 전체 시스템 흐름을 망가뜨리는 구조적 결함”처럼 느낌.

특정 백엔드 API 하나가 느려지거나 실패하면, 사용자에게는 전체 서비스가 느리거나 망가진 것처럼 보이게 됨.

• 특정 백앤드의 API 응답이 느려서 TIMEOUT이 떨어지게 되고, 그 서버에 요청이 쌓이고 BFF 중간서버에서도 요청이 쌓이면서 서로 연쇄적으로 서버가 망가지는 현상이 생김. 그래서 결국 클라이언트까지 전달되어 기능과 UI가 전부 망가지는 현상 발생함.
  • REQUEST 연결 수의 한계치를 두는 것은 도움은 되겠지만 해결은 할 수 없어서 한번 더 고민 해 봄.

트래픽 최적화를 위해 캐싱을 적용했지만, 구조적으로 한계가 예상.

API Gateway 레벨에서 endpoint별 캐싱을 적용했고,

일부 정적/모듈 응답 경로에서는 일정 수준의 성능 개선과 부하 완화 됬음.

하지만 시스템 구조상 다음과 같은 잠재적 한계가 분명히 존재함.

• 백엔드 API 자체의 불안정성 가능성 (장애, 지연, 부하에 취약한 경로)
• 사용자 트래픽이 폭증할 경우, 캐시가 만료되지 않았더라도 캐시 응답을 제공하는 서버 또는 미들웨어가 과부하에 직면할 수 있다는 점
  • 물론 이런 폭발적인 트래픽이 발생 하지는 않을거 같지만.. ㅎ