Незнание технических лимитов платформы — дорогостоящая ошибка. Это обнаруживается в самый неподходящий момент: в разгар рассылки на 5000 подписчиков, когда бот вдруг перестаёт отправлять сообщения. Или при загрузке каталога, когда выясняется, что файл слишком большой. Или при масштабировании, когда бот начинает «задыхаться» под нагрузкой.
Понять ограничения заранее — значит спроектировать архитектуру правильно с первого раза.
Почему лимиты важны для планирования
Лимиты платформы — это не произвол. Они защищают всех пользователей от спама и перегрузки инфраструктуры. MAX как молодая и растущая платформа устанавливает разумные ограничения, чтобы масштабироваться контролируемо.
Для бизнеса это означает: прежде чем проектировать бота, нужно понять, что платформа позволяет делать, а что — нет. Это влияет на архитектуру, выбор инструментов и итоговую стоимость разработки.
Основные технические ограничения
Частота сообщений. MAX Bot API ограничивает количество сообщений, которые бот может отправить в единицу времени. При превышении лимита API возвращает ошибку 429 (Too Many Requests). Это означает, что при рассылках нельзя отправлять все сообщения «залпом» — нужна очередь с контролируемой скоростью.
Размер файлов. Существуют ограничения на размер отправляемых файлов:
| Тип контента | Максимальный размер |
|---|---|
| Фото | 10 МБ |
| Видео | 50 МБ |
| Аудио | 20 МБ |
| Документ (PDF, DOC и др.) | 50 МБ |
| Текстовое сообщение | ~4096 символов |
Файлы больше лимита нужно хранить на внешнем хостинге и передавать клиенту ссылку, а не файл напрямую.
Длина текста сообщения. Одно сообщение — около 4000 символов. Если контент длиннее — нужно разбивать на несколько сообщений. При этом слать их нужно последовательно с небольшой задержкой, иначе они могут прийти вперемешку.
Inline-клавиатуры. Количество кнопок в одном сообщении ограничено. На практике рекомендуется не более 8-10 кнопок в сетке, чтобы интерфейс оставался читаемым. Технически платформа может принять больше, но UX деградирует.
Лимиты на рассылки
Это самая критичная зона для маркетинговых ботов. Несколько ключевых моментов:
Скорость рассылки. При массовой рассылке нужно соблюдать задержку между отправками. Рекомендуемый безопасный темп — не более 20-30 сообщений в секунду для бота с большой базой. Это означает, что рассылка на 10 000 подписчиков займёт около 6-8 минут, а не секунду.
Объём базы. Нет жёсткого лимита на количество подписчиков бота — это ваша аудитория, которую вы набрали органически или через платное продвижение. Но при рассылках важна скорость.
Частота рассылок. MAX не имеет прямого лимита на количество рассылок в день, но антиспам-фильтры платформы учитывают поведенческие факторы: если большой процент получателей блокирует бота после сообщений — это сигнал нарушения.
Коммерческие рассылки. Требуют, чтобы пользователь сам инициировал общение с ботом (или явно дал согласие на рассылки). Отправка сообщений пользователям, которые не запускали вашего бота — нарушение правил платформы.
Антиспам-правила MAX
Платформа отслеживает несколько паттернов, которые классифицируются как спам:
- одинаковое сообщение большому числу пользователей за короткое время;
- высокий процент блокировок бота получателями (обычно порог — более 5%);
- отправка сообщений пользователям, не запускавшим бота;
- частое использование ссылок без контекста.
При детектировании нарушения бот может получить временное ограничение на отправку или, в серьёзных случаях, блокировку. Восстановить доступ после блокировки — долго и неприятно.
Вывод: строить рассылки только по базе пользователей, которые запускали бота и не отписывались. Никаких купленных баз.
Как работать в рамках ограничений
Очереди сообщений. Для рассылок и массовых уведомлений нужна система очередей. Вместо того чтобы отправлять 5000 сообщений одновременно, бот ставит их в очередь и отправляет с нужной скоростью. Если API возвращает ошибку 429 — отправка откладывается и повторяется через указанное в ответе время.
Хорошая очередь умеет:
- ставить задачи в приоритетную очередь (срочные уведомления — раньше массовых рассылок);
- повторять неудавшиеся отправки с экспоненциальной задержкой;
- отчитываться о статусе рассылки (сколько отправлено, сколько ошибок).
Батчинг и параллелизм. Если у вас несколько ботов или несколько аккаунтов — нагрузку можно распределить между ними. Но это требует чёткого понимания архитектуры и должно быть предусмотрено при проектировании.
Хранение крупных файлов. Вместо отправки тяжёлых файлов через API — загружаете на Яндекс.Диск, Google Drive или собственный хостинг и отправляете ссылку. Бот при этом может показывать превью (миниатюру) и кнопку «Скачать».
Разбивка длинных текстов. Если контент длиннее 4000 символов — разбиваете на части. Добавляете нумерацию («Часть 1/3») или кнопку «Читать продолжение» для лучшего UX.
Что делать при превышении лимита
Если бот получил ошибку 429:
- Не паниковать. Это временное ограничение, не блокировка.
- Соблюдать Retry-After. В ответе 429 обычно есть заголовок с временем ожидания. Именно столько нужно подождать перед повторной попыткой.
- Не повторять немедленно. Бесконечные немедленные повторные запросы только ухудшат ситуацию.
- Пересмотреть архитектуру рассылки. Если 429 приходит часто — значит, скорость отправки слишком высокая. Снизьте темп.
Лимиты и ваш бизнес: практический взгляд
| Сценарий использования | Критичные лимиты | Решение |
|---|---|---|
| Рассылка на 1000+ подписчиков | Скорость отправки | Очередь с задержкой |
| Каталог с фото товаров | Размер изображений | Сжатие до 2-3 МБ |
| PDF-документы клиентам | Размер файлов | Ссылки вместо файлов >20 МБ |
| Высокая нагрузка в часы пик | Частота сообщений | Балансировка очереди |
| Длинные инструкции | Длина текста | Разбивка на шаги |
Рекомендации при проектировании бота
Если вы планируете бот с аудиторией более 1000 подписчиков — сразу закладывайте правильную архитектуру:
- система очередей для рассылок (RabbitMQ, Redis + Celery или аналоги);
- обработка ошибок API с повторными попытками;
- логирование всех API-ответов для диагностики;
- мониторинг доли блокировок бота в базе;
- возможность мягкой остановки рассылки без потери очереди.
Это не усложнение ради усложнения — это разница между ботом, который работает при нагрузке, и ботом, который падает в ответственный момент.
Правильно спроектированный бот с учётом лимитов не просто соответствует правилам платформы — он надёжен, масштабируем и не создаёт проблем в самый неподходящий момент.