주문 트래픽 20배를 견디는 재고 처리 구조 만들기

문제 상황

• 공동구매처럼 짧은 시간에 트래픽이 몰릴 때 재고 처리 구간의 lock 경합으로 slow query, timeout, 500 에러가 반복 발생
• 트랜잭션 내 재고 row 직접 갱신 구조 때문에 먼저 들어온 요청이 lock을 잡고 뒤 요청이 대기하며 DB 프로세스가 적체
• DBA가 실시간으로 slow query를 모니터링하고 오래 잡은 쿼리를 직접 kill해야 하는 운영 부담 발생

원인 분석

• 느린 쿼리의 본질이 실행 시간보다 row lock 대기 시간 증가에 있었음
• 재고 변경 경로가 주문, 상품, 어드민, OPEN-API, 배치 등 여러 곳에 흩어져 병목과 복구 지점이 복잡해짐
• 순간 TPS 상승 시 같은 옵션 재고를 갱신하려는 요청이 한 지점에 집중되는 구조적 경쟁 상태

해결 방법

• 재고 변경 경로를 상품 도메인 한 곳으로 단일화해 재고 관리 지점을 통합
• hot path를 Redis 중심으로 짧게 만들고 분산 락으로 동시성을 제어
• 재고 변경 이벤트를 Kafka로 비동기 발행하고 consumer가 DB 반영과 Redis TTL 갱신을 처리
• 메시지 실패 시 retry 후 fallback으로 DB 직접 변경하는 안전장치 구성