🛒 Backend Engineering · 4/9 · 약 7분

Backend Engineering 시리즈 전체 보기

재고는 한 번만 줄어야 하지만 요청이 한 번만 온다는 보장은 없다. 통신 지연과 사용자 재시도는 같은 의도를 반복하고, 서로 다른 주문은 같은 재고를 동시에 바라볼 수 있다.

가상의 한정 수량 상품을 놓고 반복과 경쟁을 따로 모델링했다. 멱등성만으로는 과판매가 남고 동시성 제어만으로는 같은 주문이 중복 차감될 수 있어, 두 방어선을 하나의 처리 경계에서 연결해야 했다.

#Backend · #Inventory · #Idempotency · #Concurrency

이 글에서 다룰 것

• 같은 의도의 반복과 서로 다른 주문의 경쟁을 구분하는 방법
• 읽기 후 쓰기가 동시 요청에서 실패하는 이유
• 멱등 기록과 재고 변경의 거래 경계를 정하는 기준

1. 멱등성과 동시성은 다른 문제다

같은 주문이 두 번 처리되는 것은 반복 문제다. 서로 다른 주문이 같은 재고를 동시에 가져가려는 것은 경쟁 문제다. 둘은 원인과 방어 방법이 다르다.

반복을 막으려면 요청이 어떤 의도에 속하는지 식별해야 한다. 경쟁을 막으려면 아직 조건을 만족할 때만 저장소가 값을 바꾸도록 해야 한다.

• 같은 의도는 여러 번 와도 하나의 처리 결과로 수렴한다.
• 서로 다른 의도는 남은 재고를 원자적으로 경쟁한다.
• 성공과 부족 결과 모두 다시 조회할 수 있게 기록한다.

2. 멱등 기록은 기존 결과를 돌려준다

처음 받은 주문 의도에 고유 식별자를 연결하고 처리 상태와 결과를 보관한다. 같은 식별자가 다시 오면 차감을 반복하지 않고 진행 중 상태나 이미 확정된 결과를 반환한다.

요청 본문이 우연히 같다는 사실만으로 같은 의도라고 판단하면 안 된다. 서로 다른 두 주문이 같은 상품과 수량을 선택할 수 있기 때문이다. 식별자는 사용자의 한 번의 행동 범위를 나타내야 한다.

요청 수신
   ↓
같은 의도 기록이 있는가? ── 예 ──→ 기존 결과 반환
   │ 아니오
   ↓
재고 조건을 만족하는가? ── 아니오 ──→ 부족 결과 기록
   │ 예
   ↓
재고 변경 + 처리 결과 기록