Лимиты API: как рассчитать и не превысить

Лимит API (rate limit) — это максимальное количество запросов, которое ваш клиент может отправить за определённый интервал времени. API-провайдеры защищают свои серверы от перегрузок и несправедливого потребления. Например, сервис погоды может разрешать 60 запросов в минуту, а поисковый — 1000 запросов в час. Если превысить лимит, вы получите HTTP-статус 429 Too Many Requests с заголовком Retry-After.

Понимание лимитов критично для стабильности вашего приложения. Без расчёта можно легко попасть в DDoS-подобную ситуацию на своей же интеграции. На 2026 год типовые лимиты публичных API:

• Twitter API: 300 запросов/15 мин (v2)
• GitHub API: 5000 запросов/час (авторизованный)
• OpenAI API: зависит от модели — 3-60 RPM

Существует несколько алгоритмов, используемых для rate limiting. Знание их механик поможет точнее проектировать клиентскую логику.

1. Fixed Window (FWA): счётчик обнуляется каждые N секунд. Например, лимит 100 запросов в минуту — сброс в начале каждой минуты. Минус: burst в конце окна может удвоить нагрузку, если не контролировать.
2. Sliding Window Log (SWL): хранит временные метки всех запросов. При новом запросе удаляются старые (вне окна). Точнее, но требует памяти O(n).
3. Sliding Window Counter (SWC): комбинация фиксированных окон. Разбивает окно на более мелкие слоты, например, минуту — на 10 секундных сегментов.
4. Token Bucket: выдача токенов с постоянной скоростью; burst-запросы возможны, пока есть запас. Используется в Redis-based решениях.
5. Leaky Bucket: запросы ставятся в очередь; если очередь переполнена — отбрасываются. Сглаживает трафик, но не допускает burst.

Выбор алгоритма зависит от сценария. Для большинства веб-приложений достаточно Token Bucket — он даёт и сглаживание, и возможность всплесков.

Базовая формула для расчёта максимального числа запросов L в окне:

где R — разрешённая скорость (запросов в секунду), W — ширина окна (в секундах), B — burst-запас (дополнительные запросы сверх R×W). Burst позволяет обрабатывать временные пики без превышения долгосрочного лимита.

Пример: API позволяет 300 запросов в минуту. Это R=5 запр/с (300/60). W=60 с. Burst=20. Тогда L=5×60+20=320. Округлённый лимит — 320 запросов в минуту. На практике burst часто не указывается — его узнают из документации.

Если burst не объявлен, считайте B=0. Но в популярных API (GitHub, OpenAI) burst заложен неявно — например, GitHub разрешает ~5000 запр/час, но можно слать до 100 за раз без задержки. Проверяйте заголовки X-RateLimit-Remaining.

Допустим, ваш сервис использует WeatherAPI.com. В документации указано: 1000 запросов в день (суммарно). Рассчитаем:

1. Определите окно: 1 день = 86400 секунд.
2. R = 1000 / 86400 ≈ 0.0116 запр/с.
3. Burst: если не указан, считаем 0. Но обычно есть burst — допустим, 50.
4. L = 0.0116 × 86400 + 50 = 1000 + 50 = 1050 запросов.

Но для практического использования вам нужен минутный лимит, чтобы не слать 1000 запросов разом. Пересчитаем на минуту: 1000 запр/день ≈ 0.694 запр/мин. Если burst минутный — 50, то L_min = 0.694 × 60 + 50 ≈ 91.6. Округляем до 92. Значит, в минуту — 92 запроса.

При превышении лимита API вернёт 429. Используйте заголовки: X-RateLimit-Limit: 92, X-RateLimit-Remaining.

• Игнорирование заголовков: не читаете Retry-After или X-RateLimit-Reset — и отправляете запросы раньше времени.
• Неверное окно: путаете скользящее окно с фиксированным. Фиксированное может дать сброс в середине секунды — и вы получите 429 даже при соблюдении средней скорости.
• Синхронная задержка: блокируете поток при ожидании — падает производительность. Используйте асинхронный семафор.
• Не учитываете несколько ключей: если у вас несколько API-ключей, общий лимит суммируется только если ключи привязаны к одному аккаунту. Иначе — лимиты отдельно.
• Жёсткие sleep(): в случае ошибки при повторных запросах используйте exponential backoff с jitter.

Проверьте документацию API: многие указывают лимит на ключ или на IP. Не путайте!

Чтобы не мучиться с дробями и ручными вычислениями, используйте Калькулятор лимитов API. Он поддерживает все популярные алгоритмы (Token Bucket, Sliding Window, Fixed Window) и мгновенно выдаёт итоговое число запросов для любого окна.

Вам нужно ввести: RPS (запросов в секунду), размер окна и burst. Калькулятор покажет лимит L, а также порекомендует заголовки для кэширования. Это сэкономит время и снизит риск ошибки.

Также пригодится для отладки интеграций: выставьте целевое RPS и проверьте, не будет ли превышения.

Реализуем токен-бакет на Python. Следующий код будет поддерживать burst и равномерную скорость.

import time

class TokenBucket:
    def __init__(self, rate, burst):
        self.rate = rate        # токенов в секунду
        self.burst = burst      # максимальный запас
        self.tokens = burst
        self.last_refill = time.time()

    def consume(self, tokens=1):
        now = time.time()
        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

# Пример: 10 запросов в секунду, burst 20
bucket = TokenBucket(10, 20)
for _ in range(22):
    if bucket.consume():
        # отправляем запрос
        pass
    else:
        time.sleep(0.1)

Аналогично для sliding window: храните список времен меток в deque.

from collections import deque

class SlidingWindow:
    def __init__(self, limit, window):
        self.limit = limit
        self.window = window  # в секундах
        self.timestamps = deque()

    def allow_request(self):
        now = time.time()
        # удаляем старые
        while self.timestamps and self.timestamps[0] < now - self.window:
            self.timestamps.popleft()
        if len(self.timestamps) < self.limit:
            self.timestamps.append(now)
            return True
        return False

• Анализируйте заголовки: используйте curl с -v, чтобы увидеть X-RateLimit-Limit, Remaining, Reset. Например: curl -v https://api.github.com. Сравните с ожиданием.
• Тестируйте на песочнице: многие API предоставляют тестовые эндпоинты без лимитов. Отлаживайте там.
• Логируйте: пишите в лог время каждого запроса и ответный код. При 429 засекайте Retry-After.
• Используйте mock-сервер: напишите простой Flask-сервер, который эмулирует rate limit. Это быстрее, чем долбиться к продакшену.

Не забывайте про Retry-After: игнорирование приводит к вееру ошибок. Он может быть в секундах или дате.

Если вашему сервису нужно больше запросов, сделайте следующее:

1. Проверьте тариф: часто лимиты растут с апгрейдом плана. Например, платный план GitHub даёт 15000 запр/час.
2. Запросите увеличение: напишите в техническую поддержку, объясните нагрузку. Могут одобрить до 2-3x.
3. Используйте несколько ключей: балансируйте между разными аккаунтами/ключами, если это не запрещено правилами.
4. Кэшируйте ответы: уменьшите число реальных запросов. Установите TTL, соответствующий требованиям свежести.

Важно: не увеличивайте burst за счёт сокращения окна — это может нарушить SLA. Планируйте запас в 20-30% от максимального лимита для равномерности.