Telegram

Overview

Telegram is a cloud-based messaging platform serving over 800 million monthly active users. Unlike WhatsApp, Telegram stores all messages in the cloud, enabling seamless multi-device access. It supports massive group chats (up to 200K members), channels with unlimited subscribers, and a rich bot platform. Its custom MTProto protocol is optimized for speed and reliability across unreliable networks.

Scale

Requirements

High-Level Architecture

Loading diagram...

Key Components

Data Model

Loading diagram...

MTProto Protocol

Telegram uses its custom MTProto protocol, designed for speed and reliability on mobile networks.

Key Design Decisions:

• Binary encoding: Messages use TL (Type Language) serialization, more compact than JSON/Protobuf
• Transport flexibility: Works over TCP, HTTP, and UDP with automatic fallback
• Encryption layers: Server-client encryption (default) and optional E2E (Secret Chats)
• Built-in ACK: Automatic resend for lost packets

Connection Optimization:

• Persistent TCP connections with keepalive
• Request pipelining — multiple RPC calls over a single connection
• Compression of large payloads using gzip
• Quick reconnection with session resumption (no full handshake)

MTProto achieves significantly faster message delivery than HTTPS-based alternatives, especially on high-latency mobile connections.

Loading diagram...

Multi-Datacenter Architecture

Telegram operates across multiple datacenters worldwide, with each user assigned to a “home” datacenter.

Datacenter Assignment:

• Users are assigned to the nearest DC at registration
• Each DC is a complete, autonomous unit with its own storage
• User data lives in their home DC

Cross-DC Communication:

• When User A (DC1) messages User B (DC3), the message routes through a high-speed inter-DC backbone
• Media files may be cached in non-home DCs for faster access
• Secret chats require both participants’ DCs to coordinate

Benefits:

• Data sovereignty: Users’ data stays in their assigned region
• Latency optimization: Most operations happen within a single DC
• Resilience: DC failures are isolated
• Regulatory compliance: Data kept in specific geographic regions

Channel Fan-Out Strategy

Channels are Telegram’s broadcast mechanism, with some having millions of subscribers. Telegram uses a read-optimized approach:

Storage Model:

• Channel messages are stored once in the channel’s message history
• Subscribers do NOT get individual copies (no write amplification)
• When a subscriber opens a channel, messages are fetched from the shared store

Notification Fan-Out:

• Only notifications (not full messages) are fanned out
• Notifications are batched and sent in bulk
• Muted channels skip notification delivery entirely

Read State Tracking:

• Each subscriber has a simple pointer (last_read_msg_id) per channel
• Unread count = latest_msg_id - last_read_msg_id
• O(1) per subscriber, no per-user message copies

This allows channels to scale to millions of subscribers without proportional storage or write costs.

Architectural Tradeoffs

# Learn From a Telegram-like System

You are an expert software architect and teacher. I want to learn from a Telegram-inspired system design (Cloud-native messaging with unlimited storage and channels) without pretending this is the exact private production architecture.

Use the following reference as a learning model. Keep assumptions visible, avoid unsupported scale claims, and explain the engineering forces behind each design choice.

---

## System Design Reference
import { Mermaid, Scale, ComponentList, ComponentCard, Requirements, Tradeoff } from '@/components/mdx';

## Overview

Telegram is a cloud-based messaging platform serving over 800 million monthly active users. Unlike WhatsApp, Telegram stores all messages in the cloud, enabling seamless multi-device access. It supports massive group chats (up to 200K members), channels with unlimited subscribers, and a rich bot platform. Its custom MTProto protocol is optimized for speed and reliability across unreliable networks.

## Scale

<Scale items={{
  "Monthly active users": "800M+",
  "Messages per day": "~15B",
  "Concurrent connections": "Millions",
  "Storage model": "Full cloud history",
}} />

## Requirements

<Requirements
  functional={[
    'Cloud-based messaging with full history sync',
    'Channels with unlimited subscribers',
    'Groups up to 200,000 members',
    'Bot platform and Bot API',
    'Secret chats with E2E encryption',
    'File sharing up to 2GB per file',
  ]}
  nonFunctional={[
    'Multi-datacenter distribution for resilience',
    'Fast delivery across unreliable networks',
    'Seamless sync across unlimited devices',
    'Scalable fan-out for million-subscriber channels',
    'High availability across geopolitical regions',
    'Efficient binary protocol (MTProto)',
  ]}
/>

## High-Level Architecture

<Mermaid chart={`graph TB
    subgraph Clients
        A[Mobile Apps]
        B[Desktop Apps]
        C[Web Apps]
        D[Bot Clients]
    end
    subgraph Edge["Edge Layer"...

[Full prompt copied to clipboard]