Implementing Bot for Notifications and Broadcasts in Mobile Application
Telegram bot as broadcast channel works better than email: open rate 70–90% vs 20–25%. But sending 50,000 messages at once means Telegram bans bot for flood. Correct broadcast implementation accounts for rate limits and job queue.
Telegram Bot API Limits You Can't Ignore
Telegram allows maximum 30 messages per second for regular bot, no more than 20 messages per minute in single chat. Exceeding returns 429 Too Many Requests with retry_after field.
So 50,000 recipients = minimum ~28 minutes pure sending at correct rate limiting. Simple loop with sendMessage fails on first sizable broadcast.
Correct approach: job queue (Bull + Redis or RabbitMQ). Each message — separate queue task, worker processes at controlled speed (25 tasks/sec with exponential backoff on 429).
Broadcast System Architecture
Server: Node.js + Bull Queue + Redis. Admin via mobile app creates broadcast (text, media, audience segment) → task enters queue → worker sends at proper speed → broadcast status updates in real time.
Mobile app — management panel: creating broadcast with rich text editor, selecting audience segments, scheduling by time, viewing stats (sent/delivered/errors).
Audience segments stored in PostgreSQL: tags, activity last N days, interface language. SQL query forms chat_id list for segment right before sending.
Push Notifications in Mobile App for Admin
When broadcast completes or error occurs (e.g., bot temporarily blocked), app notifies admin. Standard FCM push:
-
"Broadcast #42 completed: 48,231 / 50,000 delivered"— typenormal -
"Error: bot blocked by users (>30%)"— typehigh
On client (Flutter) use flutter_local_notifications for FCM notifications in foreground state, firebase_messaging for background/terminated.
Broadcast Analytics
Basic metric — delivery rate. Telegram doesn't return read confirmation (no read receipts for bot messages in private chats), but returns errors: 403 Forbidden — user blocked bot, 400 Bad Request: chat not found — user deleted account.
These errors auto-mark users inactive and exclude from next broadcasts — important for database hygiene.
Full system development (server + mobile management app) — 3–5 weeks. Integrating broadcast module into existing bot and app — 1–2 weeks.