测验：订单送达两次，零食只计一次

receive가 같은 ID·수량에 False를 반환했다. HTTP 서버는 어떤 ACK를 보내야 하는가?

• 새 적용이 없었으므로 무조건 실패 상태를 보낸다
• 원래 ID 대신 현재 시각을 ID로 만들어 응답한다
• 기존 업무가 확인됐으므로 같은 ID의 성공 ACK를 보낸다
• 중복 방지 기록을 지우고 다시 적용한 뒤 응답한다

inbox 기록을 먼저 커밋하고 stock 갱신 전에 종료하면 어떤 손실이 생기는가?

• 재시도를 이미 처리한 ID로 보고 재고 반영을 놓친다
• stock이 inbox를 읽어 다음 부팅 때 자동 증가한다
• HTTP가 재고 트랜잭션을 찾아 대신 완료해 준다
• 고유 키가 두 커밋을 묶으므로 불일치가 불가능하다

snack-7의 수량 7을 처리했는데 같은 ID의 수량 8이 왔다. 이 실습의 올바른 반응은?

• 최근 수량이 정확하다고 보고 이전 기록을 덮는다
• 수량 차이 1만 더하고 정상 중복으로 응답한다
• 새 ID를 서버가 만들어 두 번째 주문으로 저장한다
• Conflict로 거절하고 기존 업무와 재고를 보존한다

서로 다른 두 주문 ID가 각각 수량 7로 왔다. 최종 inbox와 total은?

• 내용이 같으므로 inbox 1행과 total 7이 된다
• 별개 업무이므로 inbox 2행과 total 14가 된다
• 내용 충돌이므로 inbox 0행과 total 0이 된다
• 도착 시각이 같은 경우에만 inbox 2행이 된다

HTTP 200이지만 응답의 id가 요청과 다르다. 발행자가 해야 할 일은?

• 상태 코드만 성공이면 해당 outbox를 완료 표시한다
• 응답의 ID로 현재 주문 ID를 바꾸고 계속 진행한다
• 현재 업무의 ACK로 인정하지 않고 미완료를 유지한다
• 요청 수량과 응답 길이가 같으면 완료로 처리한다

같은 디스크에서 수신 프로세스를 재시작해 중복 효과를 막았다. 아직 입증하지 못한 것은?

• 디스크 자체가 사라진 뒤에도 백업 없이 복구하는 능력
• 저장한 수신 ID를 새 프로세스가 다시 읽는 동작
• 같은 ID·내용의 재전송에 재고가 유지되는 동작
• 수신 기록과 재고를 독립 DB 연결에서 읽는 동작