핵심 요약
결제·주문 생성처럼 부작용이 있는 요청은 재시도·더블클릭으로 중복 실행될 수 있다. 클라이언트가 요청마다 고유한 Idempotency-Key를 보내고, 서버는 그 키로 "이미 처리했으면 같은 결과를 반환"하게 만들면 몇 번을 보내도 결과는 한 번이다.
1. 흐름
- 클라이언트: 결제 시도마다 UUID 키 생성·헤더로 전송(재시도 시 같은 키)
- 서버: 키가 처음이면 처리 후 결과 저장, 재요청이면 저장된 결과 반환
- 키+결과를 유니크 제약으로 원자적 저장
2. 저장 스키마(개념)
idempotency_keys(
key TEXT PRIMARY KEY,
status TEXT, -- in_progress | done
response JSONB,
created_at TIMESTAMP
)동시 중복 요청은 PK 충돌로 한쪽만 진행되게 한다.
3. 함정
- 키 없이 "주문번호 중복 체크"만 하면 경쟁 조건에서 샌다 — DB 유니크 제약으로 강제
- 처리 중(in_progress) 재요청엔 409나 대기 응답
- 키 보관 기간(예: 24h)과 만료 정책을 정할 것
자주 묻는 질문
프론트에서 버튼 비활성화로 충분하지 않나요?
네트워크 재시도·새로고침·동시 탭은 막지 못합니다. 서버 측 멱등성이 있어야 어떤 경로의 중복도 안전합니다.
키는 누가 만드나요?
보통 클라이언트가 "한 번의 결제 의도"당 하나 생성하고, 재시도 때도 같은 키를 보냅니다. 서버는 그 키로 중복을 식별합니다.
댓글 0