У партнёра сломался цикл повторов, и его интеграция начала отправлять запросы без остановки. С точки зрения сервера запросы выглядят настоящими. Если обслужить их все, остальные клиенты могут получить медленный сервис или недоступность именно тогда, когда пытаются работать.
Rate Limiting позволяет остановить часть нагрузки до того, как один потребитель использует общие ресурсы. Но лимит — не просто техническая защита. Для клиентов он становится частью правил продукта.
Что мы на самом деле ограничиваем
Можно считать запросы на пользователя, ключ API, организацию или конкретную операцию. Можно ограничивать среднюю скорость, допускать короткие всплески или контролировать число одновременных тяжёлых задач. Это разные механизмы для разных проблем.
Например, чтение карточки товара обычно стоит дешевле пересчёта сложного отчёта. Одинаковые лимиты для них могут несправедливо ограничить полезную активность и оставить лазейки для дорогой нагрузки.
Почему хороший отказ лучше общей аварии
Когда запрос превышает установленный предел, система может вернуть понятную ошибку и рекомендацию повторить позже. Для HTTP API это часто статус 429 с соответствующей информацией о повторе. Такой отказ лучше неконтролируемых таймаутов для всей клиентской базы.
Но предсказуемость обязательна. Партнёру нужно заранее знать пределы, понимать причины отказа и иметь возможность корректно замедлиться. Иначе защита превращается в скрытое изменение коммерческих условий.
Лимит в одном сервере ещё не лимит для всей системы
Если API работает на нескольких экземплярах, счётчик запросов внутри одного процесса не обеспечивает общий предел. При распределённом контроле появляется цена синхронизации, доступности общего хранилища и поведения при его отказе.
Нужно также различать лимиты и защиту от перегрузки. Ограничение на клиента не гарантирует, что суммарный поток всех клиентов окажется посильным. При реальном исчерпании мощности понадобятся отдельные механизмы admission control, очереди или сброса нагрузки.
Где проходит коммерческая граница
Я бы начал с вопроса: что именно страдает от слишком активного потребителя и сколько ресурсов занимает каждый тип операции? Затем согласовал бы правила с продуктом: общие, тарифные, партнёрские, временные исключения для легитимных пиков.
Метрика успеха — не количество ответов 429, а качество сервиса для остальных и понятность ограничений для того, кто в них упёрся.
Rate Limiting полезен, если компания умеет сказать «сейчас слишком много» одному клиенту, не нарушая обещаний всем остальным.