확인: 재전송과 새 주문은 다르다

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

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

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

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

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

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

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

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

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

   1. confirmed와 POST에서 받은 예약 ID를 남긴다
   2. rejected와 새로 계산한 예약 ID를 남긴다
   3. unconfirmed와 null 예약 ID를 남긴다
   4. confirmed와 null 예약 ID를 남긴다

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

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