System Design: Telegram

Requirements

Functional Requirements:

• Cloud-based messaging with seamless multi-device sync
• One-on-one chats, groups (up to 200K members), and broadcast channels (unlimited subscribers)
• Secret chats with end-to-end encryption (MTProto 2.0)
• Media sharing: photos, videos, files up to 2GB each
• Bots platform with inline queries and rich keyboard interactions
• Stickers, GIFs, and voice messages

Non-Functional Requirements:

• 800 million MAU, 55 billion messages per day
• Message delivery under 100ms for online users
• 99.99% availability across 5 global datacenters
• All cloud chat history accessible from any device instantly
• Support for supergroups with 200K members without degradation

Scale Estimation

55 billion messages per day equals approximately 636,000 messages per second. With an average message size of 150 bytes for text, that is ~8.25TB of text data daily. Media messages constitute roughly 30% of traffic; with an average file size of 1MB, media storage grows by ~16.5PB per day. Telegram stores all cloud chat history server-side (unlike WhatsApp), so cumulative storage is massive — estimated at over 100PB total. The bot platform processes an additional 15 billion API calls per day. Supergroups with 200K members can generate bursts of 10K+ messages per minute during active discussions.

High-Level Architecture

Telegram operates across five datacenters (DCs) distributed globally, with each user assigned to a home DC based on their phone number's country code. All of a user's data (messages, contacts, media) is mastered in their home DC and replicated to other DCs for read access. The client communicates with its assigned DC using the MTProto protocol over TCP, with automatic fallback to HTTP long-polling when TCP is blocked. Each DC runs a cluster of Front Servers that terminate MTProto connections and route requests to backend services.

The messaging flow: Client encrypts a message using MTProto (server-client encryption for cloud chats, E2E encryption for secret chats) → Front Server decrypts the transport layer → Message Router determines the recipient's home DC → if same DC, routes directly to the Delivery Service; if different DC, forwards via an inter-DC backbone link → Delivery Service writes to the message store and pushes to the recipient's connection. For secret chats, the server merely relays the encrypted payload without decrypting — it cannot read the content.

The multi-DC architecture uses a primary-replica model: writes always go to the user's home DC, and reads can be served from any DC with a freshness guarantee enforced via vector clocks. When a user travels to a different region, their client can connect to the nearest DC, which proxies requests to the home DC transparently. Session management allows multiple active sessions (phone, tablet, desktop, web) simultaneously, with real-time sync across all devices.

Core Components

MTProto Protocol Layer

MTProto 2.0 is Telegram's custom encryption and transport protocol. For cloud chats, it provides server-client encryption using AES-256-IGE with SHA-256 for integrity. For secret chats, it implements Diffie-Hellman key exchange with perfect forward secrecy and a ratcheting mechanism. The protocol includes built-in message acknowledgment, automatic reconnection, and data compression. MTProto uses a binary TL (Type Language) serialization format that is more compact than Protobuf, reducing bandwidth by approximately 30%.

Supergroup Message Distribution

Supergroups with up to 200K members require a specialized fan-out mechanism. Unlike WhatsApp's approach of storing messages per-recipient, Telegram stores messages per-channel: a single copy of each message is stored in the channel's message log, and members read from this shared log. Each member maintains a read pointer (last_read_message_id) that tracks their position. This shared-log model reduces write amplification from O(N) to O(1) per message, making 200K-member groups feasible.

Bot Platform

The Bot API is a stateless HTTP interface that wraps the internal MTProto backend. Bots receive updates via either long-polling (getUpdates) or webhooks. Each bot message goes through the same pipeline as user messages, with rate limiting applied per-bot (30 messages/sec for regular bots, 20 messages/sec per group). Inline bots process queries through a separate query routing service that caches frequently requested results (e.g., GIF search) in Redis with a 60-second TTL.

Database Design

Telegram uses a custom distributed storage engine (reportedly based on a modified version of a key-value store, not a standard database). Messages for cloud chats are stored in a log-structured format partitioned by chat_id. Each message record contains: message_id (incrementing per-chat), sender_id, text, media_refs (list of file IDs), reply_to_message_id, forward_from, date, and edit_date. For one-on-one chats, a dual-write model stores the message in both users' chat logs (enabling independent deletion). For groups and channels, a single shared log is used.

Media files are stored in a distributed blob storage system with deduplication based on content hash. Files are encrypted at rest using a per-file AES key. Large files (up to 2GB) are chunked into 512KB parts during upload, enabling resumable uploads and parallel downloads. File references (file_id) are opaque tokens encoding the DC number, volume, and local ID, allowing clients to download from the nearest DC that has the file cached.

API Design

• messages.sendMessage — MTProto RPC: {peer, message, reply_to_msg_id?, entities?} — returns the sent message with server-assigned message_id
• messages.getHistory — {peer, offset_id, offset_date, limit} — fetch paginated chat history from the shared log
• channels.createChannel — {title, about, megagroup: true} — create a supergroup or broadcast channel
• upload.saveFilePart — {file_id, file_part, bytes} — upload a file chunk; followed by messages.sendMedia to attach to a message

Scaling & Bottlenecks

The inter-DC replication is the most critical bottleneck. When a user in DC1 messages a user in DC3, the message must traverse the backbone link, introducing 50-100ms latency depending on geographic distance. Telegram mitigates this with eager replication of popular channel content to all DCs and lazy replication for one-on-one chats. During DC outages, the system enters degraded mode where affected users' write operations are queued until the home DC recovers — reads continue from replicas.

Supergroup scaling requires careful management of the shared message log. With 200K members and hundreds of messages per minute, the read fan-in (members loading history) creates a hot partition. Telegram uses a tiered cache: the most recent 1,000 messages per group are cached in RAM across multiple read replica nodes; older messages are served from disk-based storage. Notification fan-out for supergroups uses a pub/sub model where only members with notifications enabled receive push notifications — most members in large groups mute notifications.

Key Trade-offs

• Cloud storage vs. E2E encryption by default: Storing all messages server-side enables seamless multi-device sync and instant search, but means the server can technically read cloud chat content — unlike WhatsApp's E2E-by-default approach
• Custom MTProto vs. standard TLS/Signal Protocol: MTProto is optimized for Telegram's specific needs (mobile, unreliable networks, binary efficiency) but faces ongoing cryptographic scrutiny from the security community compared to the well-analyzed Signal Protocol
• Shared message log for groups vs. per-recipient storage: O(1) write amplification enables 200K-member groups, but independent message deletion per-user requires maintaining per-user visibility bitmasks
• Home DC model vs. geo-distributed writes: Mastering all user data in one DC simplifies consistency guarantees but introduces latency for users far from their home DC