Что такое rate limiting и зачем он нужен
Rate limiting — политика, ограничивающая число запросов от клиента за заданный период. Цели:
- Защита от перегрузки — предотвращает деградацию сервиса при резком росте трафика.
- Справедливое распределение ресурсов — один клиент не может занять всю пропускную способность.
- Защита от злоупотреблений — DDoS-атаки, скрейпинг, credential stuffing.
При превышении лимита API возвращает:
HTTP/1.1 429 Too Many Requests
Retry-After: 30
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1716300000
Алгоритмы rate limiting
| Алгоритм | Принцип | Особенность |
|---|---|---|
| Fixed Window | Счётчик за фиксированный период (минута, час) | Burst на границе окна |
| Sliding Window | Скользящее окно без фиксированных границ | Более точный, нет всплесков |
| Token Bucket | Бакет пополняется с заданной скоростью | Допускает burst в пределах размера бакета |
| Leaky Bucket | Очередь с фиксированной скоростью вытекания | Строго равномерная обработка |
Rate limiting в интеграциях e-commerce
Интернет-магазин с платформой персонализации делает запросы к API при каждом просмотре страницы: PDP запрашивает рекомендации, PLP — ранжирование, главная — баннеры. При трафике 100K MUV/день это ~3–5 млн API-запросов в сутки с пиками в несколько тысяч RPS.
Практические правила для интеграций:
- Кэшировать на стороне клиента. Рекомендации для конкретного userId редко меняются за одну сессию — кэш с TTL 5–15 минут снижает число запросов в 3–5 раз.
- Использовать batch-запросы. Если API поддерживает — запрашивать рекомендации для нескольких виджетов за один вызов.
- Circuit breaker. При серии ошибок 429 автоматически переключаться на fallback (популярные товары из локального кэша).
- Exponential backoff. При повторе после 429 не делать немедленный retry.
import time
def api_request_with_retry(url, max_retries=3):
for attempt in range(max_retries):
response = requests.get(url)
if response.status_code == 429:
wait = 2 ** attempt # 1, 2, 4 секунды
time.sleep(wait)
continue
return response
return None # fallback
Совет: перед flash-sale или Чёрной пятницей заранее уведомляйте вендора о прогнозируемом росте трафика — большинство платформ позволяют временно увеличить лимиты.
Типичные ошибки при работе с rate limits
- Не читать заголовки ответа — лимиты и остатки квоты в
X-RateLimit-*есть почти везде. - Retry без backoff — немедленный повтор после 429 гарантированно снова вызывает 429.
- Игнорировать лимиты до запуска — обнаруживать 429 в продакшне под реальной нагрузкой дорого.
- Не предусмотреть fallback — при недоступности API рекомендации должны падать gracefully (популярные/bestsellers), а не ломать страницу.