Ограничение частоты запросов (Rate Limiting)

Rate limiting — это техника контроля того, сколько запросов клиент (пользователь, API-ключ или IP-адрес) может сделать к системе в заданное временное окно — например, «100 запросов в минуту», — с отклонением или задержкой запросов сверх этого лимита, обычно с HTTP-ответом `429 Too Many Requests`. Он служит двум связанным, но разным целям: защите инфраструктуры от перегрузки (будь то из-за реального всплеска трафика или бага, заставляющего клиента долбить эндпоинт в цикле повторов) и обеспечению бизнес-/тарифных уровней (API-ключ бесплатного тарифа может быть ограничен 60 запросами в минуту, а платный тариф получает 6000). Почему это важно для AI/SaaS-разработчиков: rate limiting необходим везде, где API стоит за измеряемой стоимостью — это особенно верно для AI-эндпоинтов, поскольку один вызов LLM API может стоить заметно дороже по вычислениям, чем типичное чтение из базы данных, так что эндпоинт без ограничения частоты запросов — это прямой, неограниченный риск затрат, если клиент (или баг, или злоумышленник) вызывает его в тесном цикле. Это также стандартная практика для API, обращённых к сторонним разработчикам в целом, — как для предотвращения злоупотреблений, так и для создания естественной тарификации (лимиты частоты запросов — один из самых простых и распространённых способов отличить бесплатный план от платного). Как это работает: среди распространённых алгоритмов — token bucket («ведро токенов»: у каждого клиента есть ведро, пополняемое с фиксированной скоростью — скажем, один токен в секунду, максимум до 60, — и каждый запрос расходует один токен, позволяя всплески до размера ведра при этом обеспечивая устойчивую среднюю скорость) и sliding window («скользящее окно»: подсчёт запросов в перемещающемся временном окне, более точный, чем простой подсчёт по фиксированному окну, который может допустить всплеск прямо на границе окна). Ограничитель частоты запросов отслеживает использование по каждому клиенту (обычно с ключом по API-ключу или ID аутентифицированного пользователя, хранится в быстром хранилище в памяти вроде Redis, чтобы проверка добавляла минимальную задержку) и отклоняет запросы, превышающие настроенный лимит, часто включая заголовки `X-RateLimit-Remaining` и `Retry-After`, чтобы корректно ведущие себя клиенты могли плавно снижать частоту запросов. Разбор примера: API суммаризации документов на базе AI у одной SaaS-компании реально стоит им денег за каждый вызов к базовой LLM. Они настраивают лимит частоты запросов на своём API-шлюзе: API-ключи бесплатного тарифа ограничены 10 запросами в минуту, ключи платного тарифа — 500 в минуту, отслеживается через token bucket на базе Redis для каждого API-ключа. Когда в интеграции клиента бесплатного тарифа возникает баг, вызывающий повтор неудавшегося запроса в тесном цикле, ограничитель частоты запросов перехватывает это после 10-го запроса в течение минуты, возвращая `429 Too Many Requests` с заголовком `Retry-After: 45` вместо того, чтобы позволить багованному циклу накопить сотни дорогостоящих вызовов AI API — это защищает маржу компании и даёт клиентскому коду чёткий, машиночитаемый сигнал о том, когда именно нужно повторить попытку.