Scaling Telegram Bots to 10M+ Daily Active Users: Architecture & Queue Design

When high-volume bots receive thousands of concurrent updates per second, traditional polling loops and synchronous webhooks crash or get throttled by Telegram's 429 Too Many Requests limits (30 messages per second per bot broadcast limit). Here is the battle-tested enterprise architecture.

1. The 3-Tier Distributed Architecture

• Edge Ingestion Tier: Stateless Cloudflare Workers or Go HTTP ingesters that immediately return 200 OK to Telegram and push incoming payloads into a distributed message broker.
• Processing & Business Logic Tier: Worker consumers running on Redis BullMQ or Kafka that process commands, evaluate game mechanics, and query databases asynchronously.
• Throttled Outbound Dispatcher: A centralized rate-limiting queue that enforces Telegram's global 30 msg/sec broadcast ceiling with token bucket rate-limiting algorithms.

2. Implementing a Token Bucket Outbound Dispatcher

import { RateLimiterRedis } from 'rate-limiter-flexible';

const telegramRateLimiter = new RateLimiterRedis({
  storeClient: redisClient,
  keyPrefix: 'tg_send_throttle',
  points: 30, // 30 messages
  duration: 1, // per 1 second
});

export async function sendThrottledMessage(chatId, text) {
  await telegramRateLimiter.consume('global_broadcast', 1);
  return await fetch(`https://api.telegram.org/bot${TOKEN}/sendMessage`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ chat_id: chatId, text: text })
  });
}

3. Database Connection Pooling with PgBouncer & Read Replicas

Ensure PostgreSQL database queries use PgBouncer in transaction mode to prevent opening thousands of connection handles during traffic spikes.