[시스템 설계] 시나브로 Phase 01 - 명시적 락 없는 구매 처리

시나리오

시나브로 한정판 굿즈를 판매하기 위한 서비스를 만들었다. 이 서비스는 현재 토이 프로젝트 수준으로 개발이 되어있는 상황이다. 사용자가 100명 미만인 서비스라 단순 API 개발정도로도 충분히 서비스가 돌아가기에 현재까지는 문제가 없었다. 동시 접속도 없었고 판매하는 물건도 많지 않아 항상 재고의 여유가 있었다.

최근 시나브로 회사는 MD팀의 노력으로 일본에서 인기있는 만화인 먼작귀(치이카와) 굿즈 판권을 따내게 되었고 마케팅팀은 X를 활용하여 홍보를 진행했다. 극장판 치이카와: 인어 섬의 비밀이 개봉하자 굿즈를 찾는 사람이 많아졌고 X를 통해 사용자가 유입되기 시작했다.

현재 먼작귀 우산 피규어는 1,000개 가량 확보를 해놓은 상태이다.

시스템 상황

현재 시스템은 아래와 같이 구성되어 있다. 토이 프로젝트 수준이기 때문에 Single Application + Single DB 로 되어있다.

(부하 테스트를 진행하여 실제 상황과 동일하게 테스트를 진행해보자)

• Spring Boot
• MySQL
• k6

10초 동안 1,000명이 구매를 진행하였고 모두 성공하였다.
(실제 결제 모듈 등은 빠졌기 때문에 Latency 가 높지는 않다.)

그렇다면 DB를 살펴보자

1,000명이 구매한 후 재고가 무려 5개가 남아있는 상황이다.
시나브로는 쇼핑몰만 관리하고 있기에 한정된 수량만큼만 판매를 해야한다.
창고에는 실물이 1,000개만 존재하고 외부 창고 시스템은 백오더(고객이 주문한 상품의 재고가 창고에 부족하여 입고되는 대로 추후에 분할 출고하거나 발송하기로 처리된 미결 주문)를 지원하지 않기 때문이다.

운영 상황

백엔드 개발자는 이 장애를 확인하고 공유 후 재고를 0으로 변경하려던 상황이었다.
그러나 고객은 기다려주지 않고 5개를 구매한 상황이다.
토이 프로젝트 성격의 제품으로 인해 MD팀은 최소 5개의 추가 물량을 확보해야하는 상황이다..

고객에게 양해를 구한 후 출고 일정을 미루었다.
이번에는 MD팀의 각고의 노력으로 어떻게든 상황은 마무리되었다.

보완 사항

이제 개발팀은 발등에 불이 떨어진 상황이다.
다시 동일한 상황을 반복하지 않기 위해 시스템을 재편해야한다.

To be Continue...

다음 2편 보기