중복 요청 방지 멱등성 보장

1. 지금까지의 멱등성 보장

• 지금까지 멱등성이 필요한 부분은 상태 조건부 Update로 멱등하게 구현했습니다.

  • 상태 조건이 맞을 경우, 첫번째 요청으로 판단하고 수행

  • 상태 조건이 맞지 않을 경우

    → ex) RESERVED 상태만 재고 차감 로직 수행 후, CONFIRMED로 업데이트될 수 있음

    • RESERVED도, CONFIRMED도 아닌 상태: 잘못된 요청
    • 이미 CONFIRMED 상태: 이미 수행한 요청으로 판단하고 이전의 결과를 반환

• 결제의 경우 PG사를 거치기 때문에, “결제 승인”이나 “전체취소”는 여러 번 요청해도 1번만 수행됩니다.

  • PG사에서 발급한 같은 paymentKey인 경우만
  • 고객이 결제창에서 결제를 2번 하지 않는 이상, paymentKey는 동일

  → 현 서비스에서는 paymentKey에 DB 유니크 제약을 걸어, 미리 차단

2. 멱등키가 반드시 필요한 상황

• 하지만 “부분취소”의 경우, 2번째 부분취소가 있을 수 있습니다.

  • 2가지 경우

    1. 장애로 같은 부분취소 요청이 한번 더 들어온 것인가
    2. 고객이 진짜 한번 더 부분취소를 요청한 것인가

  • 최악의 경우, 요청의 바디도 같을 수 있음

    → 추가 데이터로 판별할 수 밖에 없음

3. 멱등키 관리

• “결제”와 “전체취소”는 PG사에서 발급한 결제키 (paymentKey)당 1번씩만 수행 가능합니다.

  → paymentKey를 멱등키로 사용 가능

• 부분취소는 별도의 멱등키가 따로 필요하기 때문에, 요청 시의 멱등키도 DB에 함께 저장합니다.

  • 멱등키는 동일한 결제 안에서 여러 부분취소를 구분하는 역할
  • DB에서는 {paymentKey, idempotencyKey} 조합만 유니크하면 됨