Rate limit API: как рассчитать и избежать блокировки

Rate limit (ограничение скорости) задаётся тремя числами: N — максимальное число запросов, T — временное окно (обычно секунды или минуты), и стратегия сброса (fixed или sliding). Формула для расчёта лимита на секунду:

Но в реальности вы оперируете целыми числами. Если API разрешает 1000 запросов в час, то средний R ≈ 0.278 req/s, но пиковые нагрузки не должны превышать N в любом окне T. Единицы: N — безразмерное (штуки), T — время в секундах. Типовые окна:

• Секунда — высоконагруженные внутренние API (лаги 1-100 ms);
• Минута — публичные REST API (типично 60–3000 запросов);
• Час — соцсети и карты (1000-10000 запросов/час).

Всегда уточняйте единицы окна в документации — перепутав минуту и час, получите 429.

Fixed Window — каждое окно начинается в фиксированные моменты времени (например, 00:00, 00:01). Простота, но есть риск burst: в конце окна и начале следующего можно отправить 2N запросов подряд. Пример: лимит 100 req/min, в 10:00:59 — 100 запросов, в 10:01:00 — ещё 100. Итого 200 за 2 секунды.

Sliding Window — окно скользит по времени (например, последние 60 секунд). Плавное, затратнее памяти (история временных меток). Нет burst-всплесков.

На практике для высоконагруженных систем используют Token Bucket (сглаживает burst, прост в реализации).

Дано: API Яндекс.Карт (тестовый example) — лимит 50 запросов в минуту, окно 60 сек, fixed window. Нужно обработать 200 запросов. Сколько минут потребуется?

1. Лимит на окно: N = 50, T = 60 с.
2. Первый burst: 50 запросов за 1 сек → ожидание 59 сек до следующего окна.
3. Каждое окно даёт 50 запросов. Для 200 нужно 200/50 = 4 полных окна.
4. Минимальное время: 4 * 60 = 240 секунд (4 минуты).
5. На практике требуются задержки. Добавим sleep(60 секунд) после каждого окна → итого 4 минуты.

Формула для времени ожидания при fixed window для N запросов: T_total = ceil(N / limit_per_window) * window_seconds.

Если sliding window, время меньше: примерно T_total = (N - 1) * (window_seconds / limit_per_window) + 1 ≈ 239 секунд.

# Python: Token Bucket
import time
from threading import Lock

class TokenBucket:
    def __init__(self, rate, burst):
        self.rate = rate          # токенов в секунду
        self.burst = burst        # максимум токенов
        self.tokens = burst
        self.last_refill = time.monotonic()
        self.lock = Lock()

    def consume(self, tokens=1):
        with self.lock:
            now = time.monotonic()
            elapsed = now - self.last_refill
            self.tokens = min(self.burst, self.tokens + elapsed * self.rate)
            self.last_refill = now
            if self.tokens < tokens:
                return False
            self.tokens -= tokens
            return True

# Использование
bucket = TokenBucket(rate=10, burst=20)
for i in range(25):
    if bucket.consume():
        print(f"Запрос {i} выполнен")
    else:
        print(f"Запрос {i} отклонён")
        time.sleep(0.05)

// Node.js: Token Bucket с setInterval
class TokenBucket {
  constructor(rate, burst) {
    this.rate = rate;
    this.burst = burst;
    this.tokens = burst;
    this.lastRefill = Date.now();
    setInterval(() => {
      const now = Date.now();
      const elapsed = (now - this.lastRefill) / 1000;
      this.tokens = Math.min(this.burst, this.tokens + elapsed * this.rate);
      this.lastRefill = now;
    }, 10);
  }
  consume(tokens = 1) {
    if (this.tokens >= tokens) {
      this.tokens -= tokens;
      return true;
    }
    return false;
  }
}
// Использование
const bucket = new TokenBucket(10, 20);
for (let i = 0; i < 25; i++) {
  if (bucket.consume()) console.log(`Запрос ${i} выполнен`);
  else console.log(`Запрос ${i} отклонён`);
}

В обоих случаях rate — токены в секунду, burst — максимальный накопленный. Для rate 10 и burst 20 можно выдержать пик 20 запросов мгновенно, затем не более 10 в секунду.

1. Путаница с окном. Если в документации написано "1000 req/hour", а вы реализуете окно 1 час — норм. Но многие API используют скользящее окно (sliding), и фиксированное даст ложные 429.
2. Не учитывать Retry-After. При 429 сервер часто возвращает заголовок Retry-After в секундах. Игнорируя его, вы получаете бан.
3. Token Bucket без проверки очереди. Если несколько потоков одновременно вызывают consume, нужна блокировка (lock/mutex), иначе race condition.
4. Переполнение при больших rate. Не забывайте про ограничение burst снизу (≥1), иначе tokens станет отрицательным.
5. Неверный мониторинг. Логи только ошибок — мало. Нужно логировать и успешные запросы с заголовками X-RateLimit-Remaining.

Важно: на 2026 год многие API уже перешли на sliding window. Проверьте документацию. Используйте наш Калькулятор rate limit API, чтобы быстро прикинуть лимиты.

Rate limit — лишь один из метрик API. Если вы строите продукт, полезно считать и пользовательские метрики. Сравним:

Первый шаг при 429 — проверить HTTP-заголовки ответа. Стандарт RFC 6585 рекомендует:

• X-RateLimit-Limit — лимит (max запросов за окно);
• X-RateLimit-Remaining — сколько осталось;
• X-RateLimit-Reset — Unix timestamp сброса окна.

Пример отладки на Python с логированием:

import requests

def api_call(url):
    resp = requests.get(url, headers={'User-Agent': 'my-cool-app'})
    # Логируем заголовки
    if 'X-RateLimit-Remaining' in resp.headers:
        print(f"Remaining: {resp.headers['X-RateLimit-Remaining']}")
    if resp.status_code == 429:
        retry_after = resp.headers.get('Retry-After', '1')
        print(f"429 — ждём {retry_after} сек")
        time.sleep(int(retry_after))
        return api_call(url)
    return resp.json()

Если API не возвращает эти заголовки, можно оценивать лимит эмпирически, отправляя запросы до первого 429 и замеряя интервал.

Для тестирования своей реализации используйте Калькулятор rate limit API — введите параметры, получите время ожидания.

Burst-лимит. Многие API разрешают короткий всплеск запросов, но со штрафом. Пример: 10 req/s с burst 20. В Token Bucket это решается параметром burst. Формула: actual_speed = min(rate, burst / time).

Distributed rate limit. Если несколько серверов, каждый знает только свою часть. Используйте Redis с atomic INCR и TTL (fixed window) или Sorted Set (sliding window). Пример на Redis:

-- Фиксированное окно через INCR
local key = KEYS[1] .. ':' .. math.floor(tonumber(ARGV[1])/60)
local limit = tonumber(ARGV[2])
local current = redis.call('GET', key) or 0
if (tonumber(current) + 1) > limit then
    return 0
else
    redis.call('INCR', key)
    redis.call('EXPIRE', key, 60)
    return 1
end

Per-user rate limit. Используйте ключ вида rate_limit:user_id:epohh_minute. В токен-бакете — отдельный bucket на пользователя.

Расчёт rate limit — базовая защита вашего приложения и сервера. Используйте Калькулятор rate limit API, чтобы заранее прикинуть, сколько синхронных запросов уложатся в лимит. А для метрик пользователей — Калькулятор churn rate, Калькулятор retention rate и Калькулятор CR.