개요
결제 시스템과 모임 참가 로직을 이벤트 기반으로 분리하면서 데이터 정합성을 보장하기 위해 아웃박스 패턴을 도입한 사례입니다.
문제 상황
초기 설계의 한계
모임 참가 승인 로직에서 결제 서비스를 직접 호출하는 동기식 구조로 시작했습니다.
발생한 문제들:
1. 성능 병목 현상
- Toss API 호출 대기로 DB 커넥션 장시간 점유
- 커넥션 풀 고갈 → 전체 시스템 응답 지연
- 동시 처리 능력 급격히 저하
2. 장애 전파
- Toss API 장애 시 모임 참가 기능 전체 마비
- 외부 의존성이 핵심 비즈니스 로직에 직접 영향
해결 방향: 이벤트 기반 아키텍처
왜 아웃박스 패턴인가?
메시지 큐(RabbitMQ) 도입 시 예상되는 문제점들을 해결하기 위해 아웃박스 패턴을 선택했습니다.