確認問題：再試行でお菓子の倉庫を追い詰めない

base=100, cap=250, attempt=3, jitter=0.5일 때 재시도 지연은 몇 ms인가요?

• 상한을 적용한 뒤 절반인 125ms
• 지수 증가한 뒤 절반인 200ms
• 상한을 적용하지 않은 400ms
• 지수 증가 없이 절반인 50ms

작업자가 선점 커밋 직후, 전송을 호출하기 전에 종료됐습니다. attempts는 어떻게 처리하나요?

• 수신 확인이 없으므로 새 작업자가 0으로 바꾼다
• 선점 때 소비한 값을 보존하고 재선점 때 올린다
• 실제 전송 여부를 추측하여 성공 횟수로 바꾼다
• 임대가 만료되면 이전 선점의 증가분을 되돌린다

재시도를 예약할 now+delay가 deadline과 정확히 같습니다. 시도 횟수는 남아 있습니다. 결과는?

• pending으로 예약하고 마감 이후 한 번 더 전송한다
• done으로 종료하고 수신 확인 없이 성공으로 센다
• dead와 deadline 사유를 저장하고 자동 재시도를 멈춘다
• deadline을 delay만큼 늘리고 기존 횟수로 계속한다

같은 ID·같은 수량을 더 긴 ttl로 다시 enqueue했습니다. 기존 업무는 이미 두 번 실패했습니다. 올바른 결과는?

• 새 ttl과 attempts=0을 반영하고 True를 반환한다
• 새 큐 행을 만들어 원래 업무와 병렬로 처리한다
• 원래 행을 지우고 새 접수의 순서로 교체한다
• 기존 예산과 상태를 보존하고 False를 반환한다

전달자 20개가 매번 jitter=0.5를 사용합니다. 지수 백오프만으로 보장되지 않는 것은?

• 작업자 사이 재시도 시점의 무작위 분산
• 설정한 cap에 따른 개별 지연의 최대 범위
• 같은 입력에 대해 같은 결과가 나오는 계산
• 선점 횟수에 따라 달라지는 지연 창 계산

max_attempts=3이면 run_once가 반드시 짧은 시간 안에 끝나나요?

• 그렇다. 세 번이라는 횟수가 전송의 소요 시간도 제한한다
• 아니다. send 자체의 시간 제한과 종료 정책도 필요하다
• 그렇다. 임대 만료가 진행 중인 HTTP 연결을 강제 종료한다
• 아니다. 모든 실패를 즉시 재시도해야 호출 시간을 줄인다