Конструирование системы ограничения запросов

Условие

Разработайте механизм ограничения трафика, учитывающий следующие требования:

1. Ограничивает обращения к API (например, REST или gRPC).
2. Приоритетное ограничение по IP‑адресу с возможностью дальнейшего расширения (например, по токену или идентификатору пользователя).
3. Ожидаемая нагрузка – около 1 млн активных пользователей в день.
4. Должен выдерживать всплески нагрузки.
5. Архитектура должна быть распределённой.
6. Проверка ограничения должна происходить с минимальной задержкой.
7. Обеспечить отказоустойчивость.
8. При превышении лимита возвращать понятное сообщение об ошибке. Цель – сократить количество HTTP‑запросов к сервису и защитить систему от DDoS‑атак и избыточной нагрузки.

Ответ

Разместите быстрый IP-лимит на границе, а детальные квоты — после авторизации. Для распределённого лимита применяйте атомарное общее состояние или явно распределённые бюджеты между узлами.

Миллион DAU не задаёт пиковый RPS: оцените запросы на пользователя, всплески и число ключей. Token Bucket допускает управляемые bursts; локальный аварийный лимит защищает при отказе общего хранилища. Доверяйте IP-заголовкам только от своих proxy, учитывайте NAT. Ответ — HTTP 429 или соответствующий gRPC status с понятной причиной. От объёмного DDoS, насыщения канала и дорогого TLS нужна защита выше приложения, а не только Redis-счётчик.