確認：再送と新規注文は違う

예약을 저장한 직후 서버가 응답 없이 연결을 닫았다. 클라이언트가 아는 사실은?

• 연결 오류이므로 서버의 예약 저장도 실패했다
• 요청을 썼으므로 창고 예약은 반드시 성공했다
• 응답을 못 받았으므로 업무 결과는 아직 미확인이다
• 재시도 전에는 기존 예약을 삭제해야 안전하다

재시도마다 새 UUID를 Idempotency-Key로 쓰면 어떤 문제가 생기는가?

• 키가 길어져 예약 조회 결과의 순서가 바뀐다
• 이전 요청의 응답 코드가 201에서 200으로 바뀐다
• 동일 주문의 수량 충돌을 서버가 더 엄격히 검사한다
• 서버가 재시도를 새 업무로 보고 중복 예약할 수 있다

같은 주문의 수량이 바뀌어 409를 받았다. 이번 구현이 해야 할 일은?

• 재전송을 멈추고 rejected로 남기며 기존 예약을 유지한다
• 본문 해시를 새 키로 삼아 변경 수량을 다시 예약한다
• 503과 같은 대기 정책으로 네 번까지 본문을 재전송한다
• 응답의 예약 ID를 추측해 confirmed로 표시하고 끝낸다

처리한 키를 프로세스 안의 집합에만 저장했다. 어떤 검사가 결함을 가장 직접 보여 주는가?

• 같은 프로세스에서 정상 주문을 한 번만 전송한다
• 서버를 재시작하고 같은 원장에 같은 입력을 다시 보낸다
• 처음 보는 다른 주문 세 개를 연속해서 전송한다
• 정상 주문 없이 잘못된 수량만 입력해 거부되는지 본다

POST에서 201과 ID를 받았지만 GET 조회가 계속 실패했다. 이번 결과 계약에 맞는 기록은?

• confirmed와 POST에서 받은 예약 ID를 남긴다
• rejected와 새로 계산한 예약 ID를 남긴다
• unconfirmed와 null 예약 ID를 남긴다
• confirmed와 null 예약 ID를 남긴다

창고가 모든 POST에 계속 503을 반환한다. 이번 실습에서 올바른 종료는?

• 네 번마다 키를 바꾸고 성공할 때까지 계속 시도한다
• 첫 503을 계약 오류로 보고 rejected로 바로 종료한다
• 네 번의 실패를 세 개의 성공 예약으로 바꾸어 기록한다
• 최대 네 번 시도하고 unconfirmed를 남긴 뒤 중단한다