测验：恢复在ACK之后终止的发送进程

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

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

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

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

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

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

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

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

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

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

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

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