거래 요청 응답이 유실된 뒤 같은 inventory 거래를 재시도해도 복제되지 않게 하려면 무엇을 저장하나요?

응답 유실을 새 거래로 오해하지 않으려면 trade_id 또는 idempotency key를 실제 inventory 전이와 같은 내구 경계에 연결해야 합니다. 예를 들어 t-77이 P1의 i-101을 P2로 옮긴 뒤 ownership commit 후 응답 전에 끊겼다면, 재시도는 새 검을 만들지 않고 t-77=committed와 결과 참조를 반환해야 합니다. record만 별도 DB에 저장하면 record는 committed인데 item은 아직 P1에 있는 불일치가 생길 수 있습니다.

저장 record에는 key, 요청 fingerprint, 인증 actor, source/destination, item 또는 stack ID, 기대 version, 상태(accepted/prepared/committing/committed/reconciling), 결과, created/expiry를 둡니다. 같은 key·같은 fingerprint의 동시 요청 두 개는 한 쪽이 unique key를 선점하고 다른 쪽은 그 상태를 조회합니다. 같은 key인데 item이나 대상이 다르면 기존 성공을 재사용하지 않고 conflict로 거절합니다. 단일 DB에서는 양쪽 owner 변경과 record를 한 transaction으로 묶고, 서로 다른 서비스라면 saga·조정 상태·양쪽 ledger와 대사 정책이 필요합니다.

상태 trace도 중요합니다. accepted는 아직 ownership이 바뀌지 않은 접수이고 committed만 내구 소유권 전이를 뜻하게 하면 응답 재조회가 명확합니다. P1 제거 후 P2 추가 전에 장애가 나면 in_transit/reconciling으로 남기고 repair가 ledger와 inventory를 비교합니다. 이미 P2가 item을 소비했다면 원래 state를 덮어써 되돌리지 않고 correction event와 경제 효과를 조사합니다. key를 너무 일찍 만료하면 오래된 retry가 새 거래가 될 수 있으므로 client retry, queue redelivery, 복구 지연을 포함해 보존합니다. 외부 메일·보상은 outbox/inbox로 inventory commit과 구분하고, 멱등 보장 범위와 보상 지연을 운영 지표로 감시합니다.