Rate limits Telegram Bot API

Рейт-лимиты для Telegram-ботов — ключевое ограничение при проектировании broadcast-механик. Лимиты применяются на стороне MTProto-серверов Telegram, обойти их через self-hosted gateway нельзя.

Лимиты

• Лимиты не специфицированы официально — Telegram оставляет за собой право менять их.
• editMessageText / editMessageCaption расходуют тот же бюджет, что и sendMessage.
• При превышении — HTTP 429 с retry_after (секунды). На это время блокируются все запросы бота, включая getUpdates.

Self-hosted Bot API Server

telegram-bot-api не снимает rate limits — они применяются на уровне MTProto-серверов Telegram. Подтверждено мейнтейнером в issue #516.

Реальные преимущества: файлы до 2 GB, HTTP webhooks, локальный file_path.

Paid Broadcasts

Параметр allow_paid_broadcast (с Bot API 7.11, октябрь 2024). Снимает лимит до 1000 msg/s за 0.1 Stars/сообщение. Требования: 100k Stars (~$1300) на балансе + 100k MAU. Не применяется к edit-методам — только к send.

Паттерн: очередь с приоритетами

Для ботов с broadcast-механикой (уведомления подписчикам, обновление сообщений) — in-memory очередь:

• Глобальная на бота, все исходящие вызовы идут через неё
• Приоритеты: instant (SOS, answerCallbackQuery) → high (ответы пользователю) → normal (уведомления) → bulk (broadcast, mass edit)
• Throttle: таймер с интервалом = 1000/лимит ms (для TG: ~40ms = 25 req/s с запасом)
• Backoff: при 429 — пауза на retry_after, элемент возвращается в очередь
• Instant-приоритет — bypass очереди

Антипаттерн: edit ALL на каждое действие

Если при каждом действии пользователя (join/leave) обновляются сообщения всех получателей broadcast — это O(U) edits на одно действие. При U=30 и двух действиях подряд — 60 edits, гарантированный 429.

Решение: обновлять только сообщение того пользователя, который совершил действие. Остальные увидят актуальные данные при своём следующем взаимодействии. Массовое обновление — только для редких критичных событий (старт, отмена).