시간 초과는 서버가 아무 일도 하지 않았다는 뜻이 아닙니다
클라이언트가 응답을 받지 못한 이유는 여러 가지입니다. 요청이 서버에 닿기 전에 끊겼을 수도 있고, 서버가 주문을 만든 뒤 응답이 돌아오는 길에 사라졌을 수도 있습니다. 클라이언트만 보면 두 상태가 모두 ‘응답 없음’으로 보일 수 있습니다.
두 번째 상태에서 새 주문 요청을 보내면 같은 주문이 두 번 만들어질 수 있습니다. 따라서 부작용이 있는 작업은 재시도 전에 원래 처리 상태를 확인할 방법이 필요합니다.
멱등성은 같은 논리 작업의 반복 효과를 한 번으로 묶습니다
RFC 9110은 멱등하지 않은 요청을 자동으로 재시도하려면 원래 요청이 적용되지 않았음을 알거나 요청 의미를 멱등하게 만드는 수단이 필요하다고 설명합니다.
이 활동에서는 논리 주문마다 고유한 작업 키를 붙입니다. 재시도에서 같은 키와 같은 요청을 보내면 서버가 이미 만든 결과를 찾아 반환하고 새 주문을 만들지 않는다고 가정합니다. 다른 주문에는 새 키를 써야 합니다.
참고 · R. Fielding, M. Nottingham, J. Reschke · RFC Editor (2022-06) — 멱등한 요청과 재시도 ↗
키만 같다고 모든 문제가 해결되지는 않습니다
같은 키에 서로 다른 요청 본문을 붙이면 충돌로 다뤄야 합니다. 서버가 키를 얼마나 오래 보관하는지, 처리 중 요청과 완료 요청을 어떻게 구분하는지, 외부 결제와 재고가 같은 거래 경계에 있는지도 설계해야 합니다.
응답을 못 받았다는 이유로 무조건 재시도하거나, 재시도를 금지하는 것 모두 충분하지 않습니다. 조회 가능한 작업 상태, 안정적인 작업 키, 사후 확인 기록을 함께 두어야 합니다.