Rate limiting и quotas

Ограничение частоты запросов — механизм защиты и обеспечения честности бэкенда, ограничивающий количество запросов, которые клиент (идентифицируемый по IP-адресу, API-ключу или аутентифицированному пользователю через JWT или OAuth 2.0) может делать к сервису в заданном временном окне, предотвращая злоупотребления, DoS-атаки и исчерпание ресурсов. Распространённые алгоритмы ограничения частоты запросов: token bucket (допускает короткие всплески), leaky bucket (применяет ровную скорость вывода) и fixed window counter / sliding window log (проще, но уязвимы к граничным всплескам) — каждый предлагает свои компромиссы между допуском всплесков и сложностью реализации. Состояние ограничения частоты запросов обычно хранится в Redis через атомарные команды INCR и EXPIRE или упорядоченные множества для реализаций скользящего окна, что делает его естественно согласованным по всем горизонтально масштабируемым экземплярам REST API-сервиса. Когда клиент превышает порог, сервер отвечает 429 Too Many Requests с заголовком Retry-After, указывающим, когда клиент может возобновить работу; эти события должны инкрементировать счётчики Prometheus, чтобы алертинг мог отличить законный рост трафика от злоумышленного скрейпинга. Ограничение частоты запросов может применяться на нескольких уровнях: в обратном прокси NGINX или API-шлюзе (глобальное ограничение), в middleware приложения (квоты на пользователя или эндпоинт) и в аннотациях Kubernetes Ingress; стратегия описывается и применяется через спецификации OpenAPI / Swagger для прозрачности потребителей API.

Как это работает

Rate limiting и quotas имеет три доминирующих стиля: REST (resource-oriented, использует HTTP-семантику, легко кешируется), GraphQL (клиент выбирает форму, один endpoint, хорошо для разных клиентов), gRPC/RPC (вызов процедур, строгая схема, низкий overhead). Хороший API предсказуем: консистентные имена, версионирован (/v1/users), пагинация для коллекций (курсор лучше offset), фильтруем, идемпотентен где безопасно, задокументирован (OpenAPI для REST, .proto для gRPC, schema для GraphQL).

Когда применять

REST — для публичных API, которые потребляет много третьих сторон: lowest common denominator. GraphQL — когда один backend обслуживает много форм клиента (web + iOS + Android с разными нуждами) и хотите избежать bespoke endpoint на клиента. gRPC — для internal service-to-service, где важны latency + типизированные контракты. Микс ок: публичный REST + internal gRPC — частый кейс.

Типичные ошибки

Ловушки Rate limiting и quotas: нет версионирования ("добавим версию потом" — к тому моменту breaking change для всех); глубоко вложенные ресурсы (/users/123/orders/456/items/789 — плоский лучше); chatty API (клиент делает 10 вызовов на одну страницу — батчите или expand related); утечка внутренних ID (auto-increment integer выдаёт объём — UUID лучше); непоследовательный формат ошибок. Пишите доки API так, будто их прочитает незнакомец.

Связанные понятия

• API дизайн
• REST API и Richardson Maturity
• GraphQL
• gRPC