Quiz: Error Handling and Reprocessing

게이트웨이·서비스A·서비스B 가 각각 4회씩 재시도할 때 사용자 클릭 한 번이 최종 시스템에 만드는 최대 요청 수는?

• 4회 — 마지막 계층의 재시도만 최종 시스템에 닿는다
• 64회 — 4 × 4 × 4
• 12회 — 4 + 4 + 4
• 16회 — 4 × 4, 게이트웨이는 세지 않는다

지수 백오프에 지터(jitter)를 넣지 않으면 발생하는 문제는?

• 대기 시간이 계속 두 배로 늘어 마지막 재시도가 지나치게 늦어진다
• 간격 계산에 상한이 없어져 재시도가 사실상 무한히 이어진다
• 여러 클라이언트가 같은 순간에 재시도해 회복 중인 서버를 다시 쓰러뜨린다
• 대기 중인 요청 객체가 쌓여 클라이언트 메모리 사용량이 늘어난다

HTTP 429(Too Many Requests)를 받았을 때 올바른 대응은?

• 즉시 재시도한다
• 재시도하지 않고 즉시 DLQ 로 보낸다
• Retry-After 헤더를 존중해 그 시간 이후에 재시도한다
• 요청 크기를 줄여 재전송한다

DLQ 에 원본 메시지만 저장하고 사유·시도횟수·최초실패시각을 빠뜨리면 생기는 문제는?

• 같은 메시지가 여러 번 쌓이면서 저장 공간을 불필요하게 쓰게 된다
• 보관 기간을 판단할 근거가 없어 정리 배치가 메시지를 지워 버린다
• 재처리 대상이 계속 쌓여 원래 큐의 처리까지 밀리게 된다
• 나중에 재처리 여부를 판단할 근거가 없어 사실상 조용히 버린 것과 같아진다

멱등성(idempotency)을 가장 정확히 설명한 것은?

• 같은 요청에 항상 같은 응답을 반환하는 성질
• 같은 요청을 여러 번 처리해도 부수 효과가 한 번만 발생하는 성질
• 요청이 반드시 한 번만 전달되는 성질
• 요청을 순서대로 처리하는 성질

중복 방어를 SELECT 로 조회 후 없으면 INSERT 로 구현했을 때의 문제는?

• 조회와 삽입을 두 번 왕복하므로 처리량이 눈에 띄게 떨어진다
• 두 문장을 한 트랜잭션으로 묶을 수 없어 부분 실패가 남는다
• 조회 조건이 인덱스를 타지 못해 건수가 늘수록 급격히 느려진다
• 조회와 삽입 사이에 틈이 있어 동시에 두 건이 들어오면 둘 다 통과한다

멱등 이력 테이블의 보관 기간을 정할 때 기준으로 삼아야 할 것은?

• 디스크 용량
• 감사 로그 보존 기간과 동일하게
• 현실적으로 재전송이 들어올 수 있는 최대 기간보다 길게
• 테이블 행 수 상한