Почему массовая рассылка через Telegram требует очереди задач?
Мы получаем много запросов на интеграцию Telegram-бота для рассылок. Open rate таких сообщений достигает 70–90% — против 20–25% у email. Но прямая отправка 50 000 сообщений за раз гарантированно приводит к бану: Telegram отвечает ошибкой 429 Too Many Requests. Правильная реализация требует учёта rate limits и очереди задач. Мы предлагаем готовое решение под ключ, учитывающее все нюансы Telegram Bot API.
В этой статье вы узнаете, как построить отказоустойчивую систему рассылок, избежать бана и обеспечить доставку 99% сообщений. Мы поделимся архитектурными решениями, которые используем в коммерческих проектах.
Типичные проблемы клиентов: бот блокируется после первой массовой отправки, падает производительность из-за отсутствия буферизации, нет инструментов сегментации. Эти проблемы решаются с помощью очередей задач и динамической сегментации.
Многие разработчики пытаются обойти ограничения через мультиаккаунты или увеличение интервала. Это неэффективно: мультиаккаунты нарушают правила Telegram, а увеличение интервала растягивает рассылку на часы. Наш подход использует официальные возможности API и гарантирует соблюдение лимитов без риска бана.
Как Telegram ограничивает частоту сообщений?
Telegram разрешает отправлять максимум 30 сообщений в секунду для обычного бота и не более 20 сообщений в минуту в один чат. При превышении API возвращает 429 Too Many Requests с полем retry_after. Согласно документации Telegram Bot API, эти лимиты жёсткие.
50 000 получателей = минимум ~28 минут чистой отправки при правильном rate limiting. Реализация через простой цикл for с sendMessage упадёт на первой же крупной рассылке.
Правильный подход: очередь задач (Bull + Redis или RabbitMQ). Каждое сообщение — отдельная задача в очереди, воркер обрабатывает их с контролируемой скоростью (25 задач/сек с экспоненциальным backoff при 429).
Как организовать очередь задач для массовой рассылки?
Серверная часть: Node.js + Bull Queue + Redis. Администратор через мобильное приложение создаёт рассылку (текст, медиа, сегмент аудитории) → задача попадает в очередь → воркер отправляет с нужной скоростью → статус рассылки обновляется в реальном времени. Такой подход гарантирует, что бот не превысит лимиты и не будет забанен.
Мобильное приложение — панель управления: создание рассылки с rich text редактором, выбор сегментов аудитории, планирование по времени, просмотр статистики (отправлено/доставлено/ошибки).
Сегменты аудитории хранятся в PostgreSQL: теги, активность за последние N дней, язык интерфейса. SQL-запрос формирует список chat_id для конкретного сегмента прямо перед отправкой.
Как настроить очередь задач: пошаговая инструкция
- Установите Redis и запустите сервер.
- Создайте очередь в Node.js с помощью Bull:
const Queue = require('bull'); const messageQueue = new Queue('notifications', { redis: { port: 6379 } }); - Добавьте в очередь задачу при получении команды от админа:
messageQueue.add({ chatId, text }); - Настройте воркер с ограничением скорости: 25 задач в секунду, с повтором при ошибке 429 через 5 секунд.
- Запустите несколько воркеров для параллельной обработки.
Сравнение: очередь задач против цикла for
Очередь с backoff в 10 раз надёжнее прямого цикла for — при 50 000 получателей она снижает число ошибок 429 до нуля. Цикл for блокирует бота, очередь же адаптируется к лимитам.
Push-уведомления для администратора
Отметим: когда рассылка завершена или возникла ошибка (например, бот временно заблокирован), приложение должно уведомить администратора. Используем FCM push:
- "Рассылка #42 завершена: 48 231 / 50 000 доставлено" — тип normal
- "Ошибка: бот заблокирован пользователями (>30%)" — тип high
На клиенте (Flutter) используем flutter_local_notifications для foreground, firebase_messaging для background/terminated.
Аналитика и поддержание чистоты базы
Базовая метрика — delivery rate. Telegram не возвращает факт прочтения (нет read receipts для bot messages в личных чатах), но возвращает ошибки: 403 Forbidden — пользователь заблокировал бота, 400 Bad Request: chat not found — пользователь удалил аккаунт.
Эти ошибки автоматически помечают пользователей как неактивных и исключают из следующих рассылок — это важно для поддержания чистоты базы.
Что входит в работу
| Этап | Содержание | Срок |
|---|---|---|
| Аналитика | Аудит текущей архитектуры, определение сегментов, настройка метрик | 3–5 дней |
| Проектирование | Разработка схемы очередей, выбор стека, создание ТЗ | 5–7 дней |
| Реализация | Серверная часть (Node.js + Bull + Redis), мобильное приложение (Flutter), интеграция Telegram Bot API | 10–15 дней |
| Тестирование | Нагрузочное тестирование (имитация 50 000 сообщений), проверка rate limiting | 3–5 дней |
| Деплой | Настройка сервера, мониторинг, документация, обучение администратора | 2–3 дня |
Сравнение подходов к очередям
| Решение | Производительность | Сложность | Поддержка |
|---|---|---|---|
| Bull + Redis | 50 000 сообщений за 3–5 минут | Низкая | Отличная |
| RabbitMQ | 50 000 за 2–3 минуты | Средняя | Хорошая |
| Google Cloud Tasks | 50 000 за 1–2 минуты | Высокая | Требуется GCP |
Пример конфигурации очереди в Node.js
const Queue = require('bull'); const messageQueue = new Queue('notifications', { redis: { port: 6379 } }); messageQueue.process(async (job) => { try { await bot.sendMessage(job.data.chatId, job.data.text); } catch (error) { if (error.response && error.response.statusCode === 429) { const retryAfter = error.response.body.retry_after; await job.retry({ delay: retryAfter * 1000 }); } } }); Ориентировочные сроки
Полная система (сервер + мобильное приложение) — от 3 до 5 недель. Интеграция модуля в существующий бот и приложение — от 1 до 2 недель. Стоимость рассчитывается индивидуально после оценки объёма работ.
Свяжитесь с нами для детального обсуждения вашего проекта. Закажите консультацию — мы подберём оптимальное решение под ваши задачи.