Rate Limit, 내 요청을 어떻게 처리할까?
Rate Limit은 특정 시간 내에 클라이언트가 보낼 수 있는 요청 수를 제한하며, 이 한도를 초과하면 429 응답을 반환합니다. 이 제한은 한 클라이언트가 전체 시스템의 용량을 독점하는 것을 막기 위해 존재합니다. 따라서 올바른 대응은 즉시 동일한 요청을 다시 보내는 것이 아니라 속도를 늦추는 것입니다.
대부분의 초기 통합 작업에서 흔히 저지르는 실수는 바로 즉시 재시도하는 것입니다. 이는 일시적인 거부를 지속적인 문제로 만듭니다. 클라이언트가 한도에 도달하여 재시도하면 측정 기간이 연장되고, 결국 원래 필요한 시간보다 훨씬 더 오랫동안 스로틀링(throttling) 상태에 놓이게 됩니다. 이 과정에서 개발자는 API가 신뢰할 수 없다고 결론 내리곤 합니다. 본 영상에서는 계층별 임계값, 버스트 허용량, 더 엄격한 제한이 있는 엔드포인트 등 사용자의 구체적인 제한 구성은 의도적으로 제외했습니다. 이러한 정보는 시간이 지나도 변치 않는 버전 관리된 문서에 포함되어야 합니다.
이 템플릿은 하나의 요청을 여덟 가지 장면으로 나누어 설명합니다. 제한이 존재하는 이유, 측정 기간과 계산 방식, 429 응답의 내용, 백오프(backoff)와 지연 시간이 늘어나야 하는 이유(두 장면), 지터(jitter)와 썬더링 허드(thundering herd), Rate Limit 헤더 읽는 법, 그리고 제한에 거의 도달하지 않도록 설계하는 방법에 대해 다룹니다.
.PNG)
.PNG)
.PNG)
