HTTP 429·503·504가 오면 모두 같은 방식으로 재시도해도 되나요?

상태 코드의 의미와 요청의 실행 가능성·멱등성·전체 deadline을 함께 봐야 합니다. 제한·일시 장애·상위 gateway timeout은 서로 다른 신호이며 코드 하나로 원본 변경이 없었다고 단정할 수 없습니다.

동작 원리와 전제

429는 제한 정책을, 503은 일시적인 서비스 불가를 나타낼 수 있어 Retry-After를 참고합니다. 504는 gateway가 제때 응답을 못 받았다는 뜻이며 원본이 이미 변경했을 수 있습니다. 네트워크 단절도 같은 불확정 결과를 만들 수 있습니다.

선택과 실패 처리

읽기는 제한된 백오프로 재시도하기 쉽지만 결제·예약은 논리 요청 ID와 결과 조회가 필요합니다. Retry-After가 있어도 남은 사용자 deadline을 넘으면 기다리지 않습니다. 모든 계층이 각각 재시도하면 호출 수가 곱해지므로 예산을 한곳에서 조정합니다.

구체적인 사례와 검증

같은 503이라도 서버가 요청을 받기 전에 거절했는지 처리 중 예외로 응답했는지에 따라 변경 가능성이 다릅니다. 상태 코드에 그 세부가 없으면 안전한 쪽으로 불확정 결과를 다룹니다. 클라이언트가 429를 즉시 반복하면 제한 상태를 더 오래 유지시킬 수 있어 지연·지터·시도 상한이 필요합니다. 요청별 deadline 안에 다음 시도와 결과 정리 시간이 들어오는지 계산합니다. 운영 지표는 최종 성공률뿐 아니라 원본 사용자 요청 수 대비 실제 시도 수를 함께 기록해야 재시도 폭주를 볼 수 있습니다. 서버가 반환한 정상 거절을 무조건 장애로 세지 않되 용량 부족으로 유효 요청을 막은 실패도 숨기지 않습니다.

서버가 제한을 반환하는 부하에서 재시도 지터·총 호출 수·회복 시간을 측정합니다. 인증 실패와 잘못된 인자는 무조건 반복하지 않습니다. 재시도를 성공률만으로 평가하지 않고 중복 효과·하위 부하·사용자 지연을 함께 확인합니다.