Bot API limits: что ломается первым при scale в Telegram

Bot API limits: что ломается первым при scale в Telegram

Когда бот начинает расти, первым упирается не код, а лимиты платформы. Bot API режет частоту отправки сообщений, число параллельных запросов и размер пачек. Если не заложить это в архитектуру, бот сначала «тормозит», потом ловит 429, а дальше уже начинается хаос с очередями и пропусками событий.

Что обычно надо проектировать сразу:
— очередь на отправку, а не прямой вызов sendMessage из бизнес-логики;
— отдельный воркер для медленных операций: медиа, уведомления, массовые ответы;
— retry с backoff и дедупликацией, чтобы не слать одно и то же дважды;
— разнесение функций по ботам, если один сценарий начинает зажимать остальные.

Вторая точка боли — Webhook и обработка апдейтов. Если хендлер отвечает долго, Telegram будет повторять доставку, а у тебя вырастут дубли и гонки. Для Mini Apps и сложных воронок это критично: сначала принимаешь апдейт, быстро ставишь задачу в очередь, и только потом делаешь тяжёлую логику. Иначе scale превращается в bottleneck на одном узком месте.

Третья проблема — хранилище состояния. Кеши, локальные сессии и in-memory-стейт ломаются при нескольких инстансах. Нужен общий стор, иначе у пользователя одна ветка диалога на одном сервере и другая на втором.

Если бот нужен под рост, считай лимиты заранее: очередь, идемпотентность, общий state и короткий ответ webhook — это не «оптимизация», а базовая схема выживания.