퀴즈: ACK 직후 꺼진 전달자를 되살린다

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

1. A는 완료 표시까지 끝났고 B 전송은 실패했으며 C는 아직 안 보냈다. 다음 배치는?

   1. A·B·C를 모두 새 업무 ID로 바꿔 다시 보낸다
   2. B가 실패했으므로 A의 완료도 되돌려 보낸다
   3. 기존 ID의 B·C가 남고 A의 완료는 유지된다
   4. B는 포기하고 C만 완료로 표시한 뒤 종료한다

2. sent=1을 HTTP 호출 전에 커밋하면 프로세스 종료 때 무엇을 잃을 수 있는가?

   1. 실제로 전송하지 못한 항목이 재조회 대상에서 빠진다
   2. 수신 DB의 고유 키가 사라져 모든 요청이 충돌한다
   3. HTTP 서버가 source DB의 표시를 자동 복구한다
   4. 전송이 한 번으로 제한되므로 누락 가능성이 없어진다

3. 서버가 두 번의 같은 HTTP 요청을 관측했고 inbox 1행·total 7·source 미완료 0개였다. 해석은?

   1. TCP가 중복 요청 하나를 제거했으므로 실제 전송은 한 번이다
   2. 서버가 두 번 반영한 뒤 데이터베이스가 자동 상쇄한 것이다
   3. 이 시험으로 모든 외부 부작용의 exactly-once가 입증됐다
   4. 두 번 전달됐지만 이 로컬 업무 효과는 한 번 적용됐다

4. pending에서 ID를 사전순으로 정렬하면 삽입 순서 보장이 깨지는 예는?

   1. a 다음 b가 접수되고 두 항목 모두 미완료인 경우
   2. z 다음 a가 접수되어 a를 먼저 반환하는 경우
   3. 같은 ID와 같은 수량이 두 번 요청된 경우
   4. 배치 상한을 16에서 8로 줄여 조회하는 경우

5. send 콜백이 전달받은 dict의 id를 바꿀 수 있다. 완료 표식은 어느 값을 써야 하는가?

   1. 콜백이 마지막으로 넣은 ID를 새 업무 기준으로 쓴다
   2. 그때 pending을 다시 조회해 첫 번째 ID를 사용한다
   3. 처음 선택한 항목을 보존하고 그 ID·내용으로 표시한다
   4. ID 대신 콜백 호출 횟수와 수량을 조합해서 표시한다

6. 실습의 단일 dispatch가 한 번 성공했다. 여러 전달 작업자로 확장하기 전에 필요한 검토는?

   1. 중복 선점·순서·임대 만료와 오래된 작업자의 완료 처리
   2. 모든 항목의 ID를 매번 현재 시각으로 바꾸는 처리
   3. 첫 실패 항목을 삭제해 미완료 수를 항상 줄이는 처리
   4. HTTP 상태 코드만 보고 완료 표시하도록 단순화하는 처리