재시도가 있는 시스템에서 멱등성이 필요한 이유는?

응답이 오지 않았다는 사실만으로 서버가 처리하지 않았다고 알 수 없기 때문이다. 같은 의도의 요청이 다시 와도 추가 결제나 추가 생성을 만들지 않는 계약이 있어야 안전하게 재시도할 수 있다.

키가 없다고 확인한 뒤 업무를 처리하고 나중에 키를 기록하면 틈이 생긴다. 같은 요청 두 개가 동시에 그 틈을 지나갈 수 있다. 키 선점과 업무 변경을 하나의 원자적 경계에 두거나, 외부 시스템도 같은 키를 받아 중복을 막게 해야 한다.

같은 키에 다른 요청 내용을 보내면 재시도로 취급하지 않는다. 이전 요청의 금액이나 상품과 비교해 불일치 오류를 내야 한다. 요청 본문만 해시해 중복을 추측하면 사용자가 똑같은 주문을 두 번 하려는 경우와 재시도를 구분하지 못한다.

키와 결과를 언제까지 보관할지도 계약이다. 클라이언트가 재시도할 수 있는 기간보다 짧으면 늦게 도착한 요청이 새 작업이 된다. 만료 시간, 자원 수명, 저장 비용을 함께 정하고 만료 뒤 동작을 문서화한다.

HTTP 메서드 이름만 보고 업무의 멱등성을 단정하지 않는다. DELETE를 여러 번 보내면 최종 자원 상태는 같을 수 있지만 응답 코드는 달라질 수 있다. 결제 취소처럼 외부 효과가 있는 작업은 메서드와 별개로 멱등 키와 상태 전이를 설계한다.