퀴즈: 되돌리기도 새 변경이다

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

1. revision 3의 주문을 취소하여 4가 됐고, 이제 그 취소를 보상합니다. 새 버전은 무엇이어야 하나요?

   1. 처음 상태를 복원하므로 revision도 3으로 낮춘다
   2. 행 상태만 바꾸고 revision 4는 계속 재사용한다
   3. 보상도 새 변경이므로 revision을 5로 증가시킨다
   4. 누구나 재시도할 수 있게 revision을 0으로 초기화한다

2. 원 changes에는 취소 승인이 있지만 해당 주문의 audit 행이 없습니다. load_plan은 어떻게 해야 하나요?

   1. 현재 cancelled 상태를 보고 빠진 감사 값을 추측해 채운다
   2. 현재 revision을 그대로 새 승인 버전으로 간주하고 계속한다
   3. 같은 건수의 다른 감사 행으로 원 기록의 빈자리를 대신한다
   4. 원 기록의 근거가 불일치하므로 Conflict로 계획 생성을 거부한다

3. undo_records의 undo_id뿐 아니라 original_id도 UNIQUE로 둔 이유는?

   1. 다른 보상 ID를 사용해 같은 원 변경을 두 번 복구하는 것을 막기 위해서다
   2. 서로 다른 원 변경도 한 번만 보상하도록 전체 테이블을 한 행으로 만들기 위해서다
   3. 사유 문자열만 같으면 모든 고객의 보상을 하나로 합치기 위해서다
   4. 현재 주문의 revision 비교를 생략하고 항상 복구해도 되게 하기 위해서다

4. 같은 undo_id와 original_id로 사유만 다르게 제출했습니다. 이미 실행한 요청으로 False를 반환해도 되나요?

   1. 된다. 사유는 문자열이므로 보상 기록의 내용에는 포함되지 않는다
   2. 안 된다. 같은 보상 번호의 다른 요청 내용이므로 Conflict다
   3. 된다. 원 변경을 보상한 뒤라면 어떤 사유도 자동으로 덮어쓴다
   4. 안 된다. 기존 보상 영수증을 삭제하고 새 요청만 남겨야 한다

5. 보상 커밋 뒤 성공 응답을 잃었고, 그 뒤 다른 담당자가 주문을 또 바꿨습니다. 동일 보상 ID의 재호출은?

   1. 현재 상태가 다르므로 원래 보상을 다시 실행해 일치시킨다
   2. 현재 테이블의 값을 기존 보상 영수증에 덮어 써서 완료로 만든다
   3. 기존 동일 영수증으로 False를 반환하며 이후 변경은 별도 대조한다
   4. 새 보상 ID를 생성하고 이후 변경을 지우는 복구를 자동 승인한다

6. DB 안에서 취소 주문 상태를 복구하는 보상이 검증됐습니다. 어디까지 적용 가능하다고 설명해야 하나요?

   1. 결제·택배·고객 이메일도 같은 트랜잭션으로 자동 복구됐다고 설명한다
   2. 클라이언트 종료 시험으로 서버 전원 장애 내구성도 증명됐다고 설명한다
   3. tenant가 있으므로 외부 호출자의 고객별 권한도 확인됐다고 설명한다
   4. 이번 DB 변경과 기록의 범위이며 외부 효과·내구성·권한은 별도라고 설명한다