Delivering Bulk Notifications via Telegram Bots and Queues

Why Your Bot Needs a Task Queue for Bulk Messaging

Telegram bot notifications have an open rate of 70–90% — compared to 20–25% for email. But sending 50,000 messages at once guarantees a ban: Telegram responds with error 429 Too Many Requests. Proper implementation requires accounting for rate limits and a task queue. Our queue-based approach is 10x faster than a simple for loop and reduces 429 errors to zero. This article covers mass messaging Telegram strategies. Our solution costs from $2,000 to $5,000 depending on scale, saving up to 30% compared to custom development. With over 4 years of experience and 30+ delivered projects, we ensure reliable implementation.

In this article, you'll learn how to build a fault-tolerant messaging system, avoid Telegram bot ban, and ensure 99% delivery. We'll share architectural decisions we use in commercial projects.

Typical client problems: the bot gets blocked after the first mass send, performance drops due to lack of buffering, no segmentation tools. These problems are solved with task queues and dynamic segmentation.

Many developers try to bypass limits via multi-accounts or increasing intervals. This is inefficient: multi-accounts violate Telegram rules, and increasing intervals stretches delivery to hours. Our approach uses official API capabilities and guarantees compliance without ban risk.

How Telegram limits message frequency?

Telegram allows a maximum of 30 messages per second for a regular bot and no more than 20 messages per minute per chat. When exceeded, the API returns 429 Too Many Requests with a retry_after field. According to Telegram Bot FAQ, rate limits are strict.

50,000 recipients = at least ~28 minutes of pure sending with proper rate limiting. Implementation via a simple for loop with sendMessage will fail on the first large campaign.

The right approach: a task queue (Bull + Redis or RabbitMQ). Each message is a separate task in the queue; a worker processes them at a controlled speed (25 tasks/sec with exponential backoff on 429). We use the task queue Bull Redis for reliability.

How to organize a task queue for mass messaging?

Server side: Node.js + Bull Queue + Redis. The admin creates a campaign via the mobile app (text, media, audience segment) → the task goes into the queue → the worker sends at the required speed → campaign status updates in real time. Our mobile app campaign management panel allows creating campaigns easily. The system provides mobile app campaign management, including audience segmentation and scheduling.

Audience segmentation Telegram is done via SQL queries: tags, activity in the last N days, interface language. An SQL query builds the chat_id list for a specific segment right before sending.

How to set up the task queue: step-by-step instructions

1. Install Redis and start the server.
2. Create a queue in Node.js with Bull: const Queue = require('bull'); const messageQueue = new Queue('notifications', { redis: { port: 6379 } });
3. Add a task to the queue when receiving a command from the admin: messageQueue.add({ chatId, text });
4. Configure the worker with rate limiting: 25 tasks per second, with retry on error 429 after 5 seconds.
5. Run multiple workers for parallel processing.

Comparison: task queue vs for loop

Queue with backoff is 10 times more reliable than a direct for loop — with 50,000 recipients, it reduces the number of 429 errors to zero. The for loop blocks the bot, while the queue adapts to limits.

Push notifications for the admin

Note: when the campaign completes or an error occurs (e.g., bot temporarily blocked), the app should notify the admin. For push notifications mobile app, we use FCM (Firebase Cloud Messaging) for admin alerts:

• "Campaign #42 completed: 48,231 / 50,000 delivered" — type normal
• "Error: bot blocked by users (>30%)" — type high

On the client, we use Flutter push notifications with flutter_local_notifications for foreground, firebase_messaging for background/terminated.

Analytics and maintaining database hygiene

We provide message delivery analytics including delivery rate and error tracking. Telegram does not return read receipts for bot messages in personal chats, but it does return errors: 403 Forbidden — user blocked the bot, 400 Bad Request: chat not found — user deleted account.

These errors automatically mark users as inactive and exclude them from future campaigns — this is important for maintaining database cleanliness and improving audience segmentation.

What's included

Comparison of queue approaches

This bot integration for newsletters simplifies bulk communication without risking bans.

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 });
    }
  }
});

Estimated timelines

Full system (server + mobile app) — from 3 to 5 weeks. Integration of the module into an existing bot and app — from 1 to 2 weeks. Cost is calculated individually after scope assessment.

Contact us for a detailed discussion of your project. Request a consultation — we'll find the optimal solution for your tasks.

Push Notifications in Mobile App: APNs, FCM, Segmentation, Rich Push

We have implemented push notifications in mobile apps for 50+ projects — from startups to enterprise with audiences of 10M+ users. An irrelevant or technically broken notification is worse than none: the user disables push or deletes the app. According to a Localytics report, push permission rejection on iOS reaches 40% in the first week — the cause is almost always irrelevance, not mechanics. Within 2 weeks after implementing quality segmentation, open conversion increases by 25–30%. Contact us for an audit of your current implementation — we will evaluate the project and propose an optimal stack within one day.

How the Infrastructure Works: APNs and FCM

APNs is the only delivery channel on iOS. Everything else (OneSignal, Braze, Airship) is a wrapper on top of it. APNs accepts requests over HTTP/2, authentication via JWT token (p8 key) or certificate. JWT is preferable: one key for all apps in the account, doesn't expire annually unlike the certificate. For more details, see the official documentation.

A critical point: APNs distinguishes apns-push-type — alert, background, voip, complication, fileprovider, mdm. An incorrect type on iOS 13+ causes background notifications not to wake the app. We've seen projects where content-available: 1 was sent without apns-push-type: background — the app didn't receive silent push on some devices, and the team spent a month looking for an 'app bug'.

FCM on Android works through Google Play Services. For devices without GMS (Huawei, part of the Chinese market), Huawei Push Kit or a direct WebSocket is needed — a separate task. FCM supports data messages (handled in onMessageReceived) and notification messages (the system displays automatically if the app is in the background). Mixing them requires caution: if the notification block has a click_action but the deep link is not registered in the app, tapping the notification simply opens the main screen without navigation.

Why Segmentation Is the Foundation of Effective Push Notifications?

Sending to everyone indiscriminately quickly exhausts user loyalty. Personalized messages are clicked 3 times more often than bulk ones, and proper segmentation reduces churn by 25% (on one project it brought significant additional revenue per quarter). The cost of setting up segmentation in OneSignal or a custom backend depends on the complexity of filters.

Proper segmentation is built on several levels.

Topics are for broad categories: 'new promotions', 'order status updates'. User subscribes via FirebaseMessaging.getInstance().subscribeToTopic("orders"). Simple, but no flexible filtering.

Attribute-based segments — via OneSignal, Braze, or custom backend. We store in the user profile: language, device type, last activity, LTV segment. Notification goes only to those with last_active < 7_days and plan = premium. OneSignal allows building such filters in the interface without code.

Personalized — by specific device_token. It's important to store tokens correctly: the token updates on app reinstall, restoration from backup on a new phone, or resetting settings. On iOS, use UNUserNotificationCenter + didRegisterForRemoteNotificationsWithDeviceToken, save to backend on every launch, not just the first. Otherwise, after 3 months 30% of tokens in the database are outdated.

What Is Rich Push and How Does It Boost Conversion?

A standard notification with title and text is clicked less often than a rich push with image and action buttons — by 3 times. But implementing rich push is a separate task on each platform.

On iOS, rich content requires UNNotificationServiceExtension (to modify payload) and UNNotificationContentExtension (custom UI). The extension runs in a separate process with limited time and memory. If the extension crashes or exceeds the timeout, the system shows the original payload without media. A typical mistake is trying to load an image over HTTP (not HTTPS): ATS blocks the request, the extension silently fails, and the user sees a notification without an image.

On Android with API 26+, notifications are tied to NotificationChannel. If the channel is created with IMPORTANCE_LOW, sound and vibration are unavailable. Different notification types (transactional, marketing) should be in different channels so the user can disable marketing without losing order notifications. BigPictureStyle, MessagingStyle, InboxStyle are templates for expanded notifications. MessagingStyle with Person and avatars is the best choice for chats.

How to Track Delivery and Conversion of Push Notifications?

Sending a notification is half the work. It's important to know: was it delivered, opened, and did it lead to a target action.

FCM returns a MessageId on send, but does not guarantee a delivery callback — by design. For open tracking, custom logic is needed: on notification tap in onMessageReceived or via getInitialNotification() / onNotificationOpenedApp (OneSignal SDK), send an event to analytics with notification_id.

OneSignal provides built-in delivery and CTR analytics. For more detailed analysis — integrate with Amplitude or Mixpanel via webhook on open events. The budget for such a dashboard varies depending on event volume.

How We Implement Push Notifications: Typical Process

1. Audit current implementation — check token storage, update handling, notification types.
2. Design architecture — choose transport (FCM + APNs), segmentation layer (OneSignal/Braze/custom), personalization method.
3. Implementation — write registration code, inbound handling, rich push, deep linking.
4. Testing — send test campaigns, verify delivery on different devices, simulators, regions.
5. Monitoring and analytics — set up dashboard, open and conversion events.
6. Documentation and training — hand over operational materials to the team.

Typical stack: FCM + APNs at transport level, OneSignal or Firebase Notifications Composer for segmentation, custom backend for personalized event-based notifications. For large apps with >1M users, OneSignal has pricing limits — then we use Braze or a custom implementation on AWS SNS.

Timelines depend on complexity: basic FCM+APNs integration with transactional notifications — 1–2 weeks. A full system with segmentation, rich push, analytics, and A/B testing — 4–8 weeks. Order an audit of your current push infrastructure or get a consultation on implementing push notifications in your mobile app — we will contact you within a day and provide an accurate estimate.