Rate Limiting Algorithms

rate-limiting-algorithms.js·3 scenarios

Loading canvas…

Что это

Rate limiting — защита от перегрузки и злоупотреблений. Принцип: ограничить число запросов от одного источника (IP, user_id, API key) за единицу времени. Главный вопрос: какой алгоритм — burst-friendly или smooth.

Как работает

Три фундаментальных алгоритма (наиболее частые в проде):

Token bucket — бакет вместимостью N токенов, пополняется со скоростью R/sec. Каждый запрос берёт 1 токен. Пустой бакет → 429. Допускает burst до capacity. Самый частый выбор для API rate limiting (AWS API Gateway, Stripe, GitHub).

Leaky bucket — буферизует burst и выпускает с постоянной скоростью. Используется когда важна гладкость output rate (traffic shaping в сетях, защита downstream от burst). При полном бакете — drop.

Sliding window counter — точный подсчёт запросов в скользящем окне (например, последние 60 секунд). Решает проблему «boundary spike» fixed window (двойная нагрузка на границе минуты). Реализация: Redis sorted set с timestamp'ами + ZREMRANGEBYSCORE.

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

Token bucket — дефолт для API rate limiting. Бытовые лимиты типа «100 req/sec на API key».

Leaky bucket — egress traffic shaping (исходящие webhook'и, CDN purges, network QoS).

Sliding window counter — distributed rate limiting через Redis. Точные лимиты «100/min/user» без boundary spike.

Fixed window — простейший, для cheap tier limits. Принимай boundary spike (2x rate на 1 секунду).

Когда НЕ стоит

Не используй token bucket для smooth egress. Burst пройдёт — downstream может не справиться.

Не используй global rate limit без partitioning. Один атакующий клиент = всем плохо.

Не считай requests на app-сервере в кластере. Distributed rate limiting через shared state (Redis/Memcached) — иначе каждый pod ограничивает «свою долю», истинный лимит ×N.

Не возвращай 429 без Retry-After. Хороший клиент будет повторять с backoff.