Architecting High-Throughput Messaging: WhatsApp, Telegram, SMS, and Beyond

# Architecting High-Throughput Messaging: WhatsApp, Telegram, SMS, and Beyond

Every notification, every OTP, every customer support message — they all look simple from the outside. Behind the scenes, a high-throughput messaging system is a carefully orchestrated dance of queues, rate limits, provider APIs, and graceful degradation. Here's how we build systems that deliver messages reliably, at any volume.

The Multi-Channel Reality

Users don't live on one platform. Your messaging system needs to reach them wherever they are:

Each channel has its own API semantics, rate limits, cost structure, and failure modes. The architecture's job is to make them feel like one unified pipe.

Core Architecture

Application Layer
      │
      ▼
┌──────────────┐
│  Message API  │  — REST + gRPC, validates, templates, enriches
└──────┬───────┘
       │
       ▼
┌──────────────┐
│   SNS/SQS     │  — Fan-out to per-channel queues
└──────┬───────┘
       │
  ┌────┼────┬────────┐
  ▼    ▼    ▼        ▼
 WA   TG   SMS    Push
Queue Queue Queue  Queue
  │    │    │        │
  ▼    ▼    ▼        ▼
Worker Worker Worker Worker
  │    │    │        │
  ▼    ▼    ▼        ▼
  WA  Tele  Twilio  APNs
  API gram  /Vonage /FCM

Why Queues?

Direct API calls from application code to provider APIs is a recipe for lost messages. A transient provider outage, a rate-limit spike, or a deployment in the wrong moment — and messages vanish silently.

By routing everything through SQS (or RabbitMQ for self-hosted deployments), we get:

• Persistence — Messages survive worker crashes
• Batching — Workers pull in batches of 10, matching provider batch APIs
• Backpressure — Queue depth controls worker scaling
• Dead Letter Queues — Failed messages go to DLQ for inspection, not the void

Per-Channel Implementation

WhatsApp Business API

WhatsApp's Cloud API is the most capable — and the most complex — channel we integrate.

Template Management: WhatsApp requires message templates to be pre-approved. We built a template synchronization pipeline that:

1. Maintains templates as code (JSON in git, reviewed via PR)
2. Syncs to WhatsApp via the Message Template API on merge
3. Polls approval status and alerts on rejection
4. Exposes approved template IDs to the application via a cache

Phone Number Rotation: High-volume senders hit per-number rate limits. We maintain a pool of sender phone numbers and distribute load across them. A quality-score-based router favours numbers with higher throughput quotas (numbers with better quality ratings get higher limits from Meta). Webhook Processing: Incoming messages arrive via webhook. Our webhook handler:

• Validates the X-Hub-Signature-256 HMAC
• Deduplicates by message ID (WhatsApp may deliver webhooks twice)
• Publishes to SNS for downstream consumers (CRM, analytics, auto-responders)

// Simplified webhook handler
export async function handleWhatsAppWebhook(body: any, signature: string) {
  const isValid = crypto.timingSafeEqual(
    crypto.createHmac('sha256', APP_SECRET).update(JSON.stringify(body)).digest(),
    Buffer.from(signature.replace('sha256=', ''), 'hex')
  );
  
  if (!isValid) throw new UnauthorizedError();
  
  for (const entry of body.entry) {
    for (const change of entry.changes) {
      for (const message of change.value.messages || []) {
        if (await isDuplicate(message.id)) continue;
        await sns.publish({
          TopicArn: WHATSAPP_INBOUND_TOPIC,
          Message: JSON.stringify(message),
          MessageDeduplicationId: message.id,
        }).promise();
      }
    }
  }
}

Telegram Bot API

Telegram's Bot API is straightforward but opinionated. Key considerations:

Polling vs. Webhooks: For high throughput, webhooks win. But Telegram only delivers one update at a time per webhook call. We run multiple webhook endpoints behind a load balancer to parallelize processing. Message Fan-Out: Broadcasting to many users requires careful rate limiting. Telegram's 30 msg/sec limit means a broadcast to 100,000 users takes ~55 minutes. We use a leaky-bucket rate limiter and parallelize across multiple bot tokens for large broadcasts. Rich Formatting: Telegram supports HTML and MarkdownV2 formatting, inline keyboards, and media attachments. Our message templating engine generates platform-specific payloads from a unified message format.

SMS (Twilio / Vonage)

SMS is the fallback channel — and often the most important one for OTPs and critical alerts.

Multi-Provider Routing: We maintain connections to both Twilio and Vonage. A cost-and-reliability router selects the provider per message based on:

• Destination country and carrier (some routes are cheaper or more reliable per provider)
• Current provider health (circuit breaker pattern)
• Message type (OTP prioritizes delivery speed over cost)

Delivery Tracking: SMS delivery is asynchronous. We poll delivery status webhooks and update message state in DynamoDB. Messages undelivered after 30 seconds trigger automatic re-delivery on the alternate provider.

Throughput Optimization

Message Batching

Provider APIs support batching where the SDK allows. We batch at multiple levels:

1. Queue batch — SQS delivers 10 messages per poll
2. Provider batch — WhatsApp Cloud API accepts arrays of messages
3. Connection pooling — HTTP keep-alive pools minimize TLS handshake overhead

Priority Queues

Not all messages are equal. We implement priority lanes:

Priority is enforced at the queue level with separate SQS queues and worker pools.

Connection Management

Persistent connections to provider APIs are critical. We run HTTP/2 connection pools with:

• Connection warming — Workers pre-establish connections before pulling messages
• Circuit breakers — After 5 consecutive failures, the circuit opens and the channel is marked degraded
• Graceful degradation — When a channel fails, messages are held (not dropped) and re-routed if possible

Observability

A messaging system without monitoring is a black box. We instrument:

• Per-channel latency — P50/P95/P99 from enqueue to provider ACK
• Delivery success rate — By channel, by country, by message type
• Queue depth — Alerts when backlog exceeds threshold
• Provider API errors — Rate-limited vs. invalid vs. auth failures
• Cost per message — Tracked per channel and destination for billing optimization

All metrics feed into CloudWatch dashboards with anomaly detection alarms.

Cost Optimization

Messaging costs add up quickly at scale. Our strategies:

• Channel preference order — Push notifications > Telegram > WhatsApp > SMS (cheapest to most expensive)
• User preference routing — Users choose their preferred channel; fallback only when critical
• Template consolidation — Fewer WhatsApp templates means fewer approval cycles
• Provider competition — Multi-provider SMS routing keeps per-message costs competitive

The Hard Part

The real challenge isn't sending messages — it's handling everything that goes wrong. A WhatsApp template gets rejected. A Twilio webhook fails silently. A user's phone number changes carriers. Every edge case needs a path, and every path needs monitoring.

The architecture described here handles millions of messages daily across three continents. When it works, nobody notices. That's the point.

---

Scaling your messaging infrastructure? We've done it before.