비동기 처리 아키텍처 흐름
기존 병목을 해결하기 위해, 비동기 기반의 아키텍처로 개편된 전체 흐름입니다. B2B 고객의 특성을 살려 즉각적인 최종 결과 응답 대신, 비동기 처리 후 별도 조회가 가능하도록 설계했습니다.

주요 해결 방안은 DB, MQ 비동기 처리 및 TimeOut 정책 도입니다.

2.1 DB 병목 현상 해결 (데이터 분할 저장)
대용량 데이터의 DB Insert로 인한 병목을 방지하기 위해 데이터의 크기에 따라 저장 방식을 이원화했습니다.

해결 방법
PK나 슈퍼키 역할을 하는 가벼운 필수 데이터는 DB에 즉시 저장하여 데이터의 무결성과 기능적 이슈를 방지합니다.
반면, 페이로드가 큰 대용량 데이터는 서버 내부 파일 시스템에 우선 적재한 뒤,
DB 자원의 여유 상태를 확인하여 비동기적으로 Insert/Update(결과 Sync) 배치나 스케쥴링을 통해 처리합니다.

2.2 MQ 통신 병목 해결 (우선순위 기반 채널 분리)
공용 Queue 채널 사용으로 인해 DB보다 심각하게 발생할 수 있는 MQ 서버의 병목 현상을 방지합니다.

해결 방법
Priority(우선순위) 발급 기능을 추가했습니다.
API의 성격에 따라 즉시 처리가 필요한 건은 Fast Channel을 타도록 유도하고, 일반 처리 건은 기존 채널을 타도록 mqAgent와 Dispatcher 로직을 수정하여 트래픽을 분산시켰습니다.

2.3 Timeout 정책 및 방어 로직 (장애 확산 방지)
시스템 내부의 특정 병목이 전체 API 통신 먹통으로 이어지는 것을 방지하기 위한 안전장치입니다.

해결 방법
각 통신 구간(특히 MQ나 비동기 로직)에 Timeout 정책을 명확히 설정했습니다.
병목 구간 발생 시 즉각적으로 Timeout 에러 응답을 발생시켜 API 스레드가 무한 대기하는 것을 막고, 별도 Response를 통해 서버 담당자에게 알림이 고지되도록 설계하여 빠른 조치가 가능하도록 구현했습니다.

해결책은 단순히 편법이 아닌, 고부하 분산 시스템에서 널리 쓰이는 표준적인 패턴들을 유사하게 구현하였습니다.

CQRS(명령과 조회의 분리) 관점 적용
API 접수와 결과 조회를 분리함으로써, 1000 TPS / 30 TPS라는 극단적인 트래픽 차이를 안정적으로 소화할 수 있는 비동기 파이프라인을 구축했습니다.

Graceful Degradation (우아한 성능 저하)
DB와 MQ 서버에 부하가 오더라도 시스템 전체가 다운되지 않고, 파일 시스템 백업 및 Timeout을 통해 부분적인 지연만 발생하도록 설계한 점은 시스템의 장애 허용력을 크게 높였습니다.

Circuit Breaker 패턴의 변형 적용
Timeout 정책을 통해 무한 대기를 끊어내고 서버 자체 알림이 발생하기전에 시스템 사용자가 확인 가능하도록 하여
MSA 환경에서 장애 전파를 막는 서킷 브레이커 패턴과 유사한 효과로 시스템 안정성에 기여했습니다.