Чому масова розсилка через 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 тижнів. Вартість розраховується індивідуально після оцінки обсягу робіт.
Зв'яжіться з нами для детального обговорення вашого проєкту. Замовте консультацію — ми підберемо оптимальне рішення під ваші завдання.