1 billion monthly active users. 70 billion messages per day. A custom encryption protocol built from scratch. And in 2025, an entire blockchain economy living inside a chat app.
Most system design guides treat Telegram like a simpler version of WhatsApp. That's completely wrong.
Telegram is architecturally one of the most interesting messaging platforms ever built — it designed its own transport protocol (MTProto), runs its own distributed cloud storage, supports channels with unlimited subscribers broadcasting to millions simultaneously, has a fully programmable Bot platform handling 1.2 billion interactions per month, and now hosts an entire Web3 ecosystem through Mini Apps and the TON blockchain.
As a senior AI PM, you need to understand why Telegram made each of these decisions, what product outcomes they serve, and what trade-offs your team would navigate building something similar.
This is Part 4 of my Core System Design & AI System Design series — built specifically for AI product managers and data professionals.
This is the breakdown that actually covers it all. 👇
📌 TL;DR
Telegram hit 1 billion MAU in March 2025 and handles 70+ billion messages daily across 5 global datacenters
MTProto 2.0 — Telegram's custom transport protocol — is the architectural backbone. It's why Telegram feels faster than every competitor, especially on weak mobile networks
Cloud-first architecture is the product decision that defines everything: your messages live in Telegram's cloud, not just your device, enabling seamless multi-device sync
Five critical subsystems: MTProto messaging layer, message storage & sync, Channels & broadcast architecture, Bot platform & Mini Apps, and security & encryption
The biggest PM insight: Telegram's "not end-to-end by default" decision is a product choice, not a security failure — it's what enables cloud sync, multi-device, and searchable history
In 2025, Telegram is no longer just a messaging app — it's a platform. Mini Apps, TON blockchain, Telegram Stars, and Bots have turned it into the world's fastest-growing super-app
Telegram End to End System Design Architecture
📊 The Numbers That Define Every Decision
Metric | Scale (2025) |
|---|---|
Monthly active users | 1 billion+ |
Daily active users | 500+ million |
Messages per day | 70+ billion |
Peak messages per second | ~1 million |
Group size limit | 200,000 members |
Channel subscribers | Unlimited |
File size per transfer | Up to 4GB |
Global datacenters | 5 (US, EU, Asia) |
Bot interactions per month | 1.2 billion+ |
Mini App users | 500+ million |
Telegram Premium subscribers | 12 million+ |
Countries with bans (survived) | 8+ |
These numbers immediately tell you what the system must do:
70 billion messages/day = ~810,000 messages/second average. The transport protocol must be extremely efficient — every wasted byte multiplies by 810,000
Cloud-first means every message is stored server-side. Storage architecture must be infinitely scalable
Groups up to 200,000 members means a single message can fan out to 200K recipients simultaneously
4GB file transfers mean the media pipeline needs chunked, resumable, CDN-distributed delivery
Multi-device sync means session management is a core product requirement, not an afterthought
Mini Apps with 500M+ users means Telegram is running a platform economy, not just a messenger
✅ Functional Requirements: What Telegram Must Do
Feature | Description | Priority |
|---|---|---|
1:1 messaging | Text, media, files up to 4GB, voice messages | P0 |
Group chats | Up to 200,000 members, admin controls | P0 |
Channels | Broadcast-only, unlimited subscribers | P0 |
Multi-device sync | Same account on phone, tablet, desktop, web simultaneously | P0 |
Secret Chats | E2E encrypted, device-local, self-destructing | P0 |
Media & file transfer | Up to 4GB, resumable, CDN-served | P0 |
Bots | Programmable agents with full messaging API | P1 |
Voice & video calls | E2E encrypted, 1:1 and group | P1 |
Mini Apps | Web apps running inside Telegram | P1 |
Telegram Stars | In-app currency for digital goods | P1 |
TON Wallet | In-chat crypto wallet | P1 |
Reactions & threads | Emoji reactions, message threading in groups | P1 |
Stories | 24-hour ephemeral content | P2 |
Telegram Premium | Subscription tier with larger limits | P2 |
💡 My Take: Notice that Secret Chats are P0 — but they're opt-in, not the default. This is the most consequential product decision Telegram ever made. Making cloud sync the default and E2E the exception enabled multi-device, searchable history, and bot integrations that WhatsApp and Signal cannot offer. Every PM working on a messaging product needs to understand this trade-off explicitly — it's not a security failure, it's a deliberate product philosophy.
⚙️ Non-Functional Requirements: Where Architecture Gets Designed
Requirement | Target | Justification |
|---|---|---|
Message delivery latency | <100ms (same DC) · <300ms (cross-DC) | Real-time feel; users notice delay above 500ms |
Availability | 99.99% | Messaging is utility — downtime is unacceptable |
Message ordering | Guaranteed per-chat | Out-of-order messages break conversations |
Delivery guarantee | At-least-once · deduplication at client | Messages cannot be lost |
Multi-device sync latency | <1s | New device sees all messages instantly |
File transfer speed | Near-saturate network bandwidth | 4GB files must feel fast |
Secret chat E2E | Perfect forward secrecy | Each session has unique keys |
Storage durability | 11 nines | Messages are permanent unless deleted |
Throughput | 1M+ messages/second peak | Election/crisis events spike dramatically |
Bot API latency | <200ms | Bot UX depends on responsiveness |
💡 My Take: Message ordering is the hardest NFR on this list and the one most PM candidates overlook. In a distributed system where a user is sending from two devices simultaneously, guaranteeing that both devices agree on message order requires a coordination mechanism that has real latency implications. Telegram's solution is server-side ordering with monotonically increasing message IDs per chat — elegant and fast, but it means the server is the single source of truth for message order. That's an architectural choice with security implications worth understanding.
🗂️ High-Level Architecture: The Five Major Subsystems
Client (iOS / Android / Desktop / Web)
↓
MTProto 2.0 Transport Layer
↓
API Gateway → Nearest Datacenter (DC1–DC5)
↓
┌─────────────────────────────────────────────────────┐
│ 1. MTProto Messaging Layer (send / receive / sync) │
│ 2. Message Storage & Multi-Device Sync │
│ 3. Channels & Broadcast Architecture │
│ 4. Bot Platform & Mini Apps │
│ 5. Security, Encryption & Secret Chats │
└─────────────────────────────────────────────────────┘
↓
Storage Layer (Distributed KV · Object Store · CDN)1️⃣ MTProto 2.0 — The Custom Protocol That Changes Everything
This is Telegram's most important architectural decision, and the one most PM candidates skip entirely.
Why Telegram Built Its Own Protocol
In 2013, every messaging app used HTTP/HTTPS over TCP. HTTP is designed for web pages — it has significant overhead (headers, handshakes, latency per request) that is acceptable when loading a webpage but catastrophic for real-time messaging on mobile networks with high latency and frequent reconnections.
Telegram's founders (who had previously built VK, Russia's largest social network) decided to design a protocol from scratch optimized for one thing: fast, reliable messaging on unreliable mobile networks.
The result was MTProto. As of version 4.6, all major clients use MTProto 2.0.
How MTProto 2.0 Works
Key properties of MTProto 2.0:
🔐 Auth key per device-DC pair: Each device maintains separate authorization keys for each of the 5 datacenters. An Android client can simultaneously maintain connections to up to 5 DCs. This means Telegram can route different types of traffic (messages vs. media vs. calls) to different DCs without re-authentication.
⚡ Session persistence: Sessions are attached to the device, not the connection. If the network drops and reconnects, the session resumes immediately. No handshake overhead on reconnection — just a new TCP connection reattaching to the existing session.
📦 Binary serialization (TL — Type Language): All messages use Telegram's own binary serialization format. Compared to JSON (used by most competitors), TL reduces message size by 60–80%. At 70 billion messages/day, this is a massive bandwidth saving.
🔄 Multiplexing: Multiple requests can be in flight simultaneously over one connection. Responses don't need to arrive in order. This makes MTProto feel dramatically faster than HTTP on high-latency connections.
The 5 Datacenters:
DC | Location | Primary use |
|---|---|---|
DC1 | Virginia, USA | US users |
DC2 | Amsterdam, Netherlands | European users |
DC3 | Miami, USA | Backup / overflow |
DC4 | Amsterdam, Netherlands | European backup |
DC5 | Singapore | Asian users |
Every user is assigned a "home DC" at registration based on geography. Messages between users on the same DC are delivered without cross-DC routing. Cross-DC messages incur additional latency (~100–200ms).
💡 My Take: Building a custom protocol is one of the most expensive and risky architectural decisions a tech company can make. Most teams would use WebSockets and call it done. Telegram's bet paid off: MTProto is genuinely faster than WebSocket-based competitors on mobile, especially in countries with poor network infrastructure. For a product competing on speed and reliability in emerging markets (India, Brazil, Southeast Asia), this was a platform-defining decision. As a PM, the lesson is: when the standard tools fail your core NFR, sometimes you have to build your own.
2️⃣ Message Storage & Multi-Device Sync
This is the architectural decision that separates Telegram from WhatsApp and Signal at a product level.
Cloud-First vs. Device-First
Approach | WhatsApp / Signal | Telegram |
|---|---|---|
Default encryption | E2E (device to device) | Server-client (cloud storage) |
Message storage | Device only | Telegram's cloud |
Multi-device sync | Limited (one phone primary) | Full sync, unlimited devices |
Message search | Local device only | Full cloud search |
New device setup | Transfer from old device | Instant — download from cloud |
Bot access to messages | Impossible | Possible (bots can read in groups) |
Message history if phone lost | Gone (unless backup) | Permanent in cloud |
Telegram's cloud-first model means your messages are stored on Telegram's servers, encrypted with keys that Telegram holds (for cloud chats). This enables everything that makes Telegram feel magical: instant sync across 10 devices, full searchable history, seamless device switching.
The security trade-off: Telegram can technically read your cloud chat messages. Secret Chats are genuinely E2E encrypted — Telegram cannot read those. But the vast majority of Telegram users use cloud chats.
Multi-Device Sync Architecture
Session management: Every device running Telegram has a unique session. The server maintains a mapping of user_id → active sessions. When a message is delivered, the server fans out update notifications to all active sessions for both sender and recipient.
Update types:
updateNewMessage— new message in any chatupdateReadHistoryInbox— someone read your messageupdateUserStatus— online/offline statusupdateEditedMessage— message was edited
All updates flow through the same MTProto connection. The client processes them sequentially per chat to maintain message ordering.
Message Storage
Message written
↓
Distributed KV store (custom — Telegram's own storage engine)
Key: (chat_id, message_id)
Value: encrypted message blob
↓
Media stored separately in object store
→ Linked to message by file_id + access_hash
→ CDN-distributed for fast download
↓
Message ID sequence maintained per chat
→ Monotonically increasing
→ Ensures ordering guarantee across devices💡 My Take: The cloud-first vs. device-first debate in messaging is actually a product philosophy debate, not a security debate. WhatsApp chose device-first because it maximized security and privacy. Telegram chose cloud-first because it maximized utility and user experience. Neither is wrong — they serve different user needs. As a PM, what's important is that you make this choice explicitly and understand its downstream implications: cloud-first enables bots, search, and multi-device; device-first enables true E2E privacy but kills all three.
3️⃣ Channels & Broadcast Architecture
Telegram Channels are architecturally different from group chats — and they're the feature that turned Telegram from a messaging app into a media platform.
The Core Difference: Groups vs. Channels
Dimension | Group chat (up to 200K) | Channel (unlimited) |
|---|---|---|
Who can post | Any member (with permissions) | Admins only |
Member cap | 200,000 | Unlimited |
Message delivery | Real-time push to all | Async fan-out |
Read receipts | Yes | No |
Reply model | Threaded or flat | Linked discussion group |
Subscriber visibility | Members can see each other | Anonymous |
Architecture | Real-time push | Pub/sub fan-out |
Channel Message Delivery Architecture
The fan-out problem: A channel with 10 million subscribers posting one message requires 10 million delivery events. Telegram handles this through a tiered fan-out system:
Active sessions (user is online): immediate push via existing MTProto connection
Inactive users (offline): message stored; push notification sent via APNs/FCM; message pulled on reconnect
Very large channels: fan-out workers process subscriber lists in batches; eventual consistency acceptable (messages delivered within seconds to minutes for offline users)
This is the same push/pull hybrid problem as Twitter's celebrity fanout — a message going to millions of subscribers cannot be synchronously pushed to all of them.
Telegram solved channel interactivity elegantly: every channel can be linked to a regular group chat. When a channel post is published, a copy appears in the linked group, and members reply in the group. The channel post shows a "View N comments" count that pulls from the group.
This means the comment system is just the group chat system — no new architecture needed.
💡 My Take: Channels became Telegram's biggest growth driver in markets like Iran, Russia, Southeast Asia, and India because they offer something no other platform provides: a broadcast medium with zero algorithmic filtering. What you post reaches 100% of your subscribers, always. No algorithmic feed, no reach suppression. For news channels, political movements, and content creators who've been throttled by Facebook and Instagram, this is a fundamentally different value proposition.
4️⃣ Bot Platform & Mini Apps
Telegram's Bot platform is architecturally one of the most sophisticated in any messaging app — and in 2025, it powers an economy larger than many standalone app stores.
Bot Architecture
Two delivery models:
Long polling: Bot repeatedly calls getUpdates every few seconds. Simple but slightly delayed. Good for bots with low message volume.
Webhooks: Telegram sends a POST request to the bot's HTTPS endpoint immediately when a message arrives. Near-zero latency. Required for high-volume bots. The bot developer's server must be publicly accessible.
Bot capabilities (as of Bot API 7.x, 2025):
Send any message type (text, media, polls, locations, contacts)
Create inline keyboards and reply keyboards
Process payments via Telegram Stars or external providers
Access group/channel admin functions
Run Mini Apps (web apps inside Telegram)
Handle voice messages, files up to 4GB
Read group message history (if admin)
Scale: 1.2 billion bot interactions per month. BotFather (Telegram's built-in bot creation tool) reached 7.3M MAU by early 2026, more than doubling from 3.5M in January 2025.
Mini Apps Architecture
Mini Apps are full web applications that run inside Telegram's built-in browser. They are built with HTML/CSS/JavaScript and communicate with the Telegram client via a JavaScript bridge.
User opens Mini App (from bot, inline button, or direct link)
↓
Telegram client opens WebView
↓
Mini App loads (HTML/JS/CSS from developer's server)
↓
JavaScript bridge: window.Telegram.WebApp
├── User data (id, name, language) — signed & verified
├── Theme data (dark/light mode, colors)
├── sendData() — send data to bot backend
├── openInvoice() — trigger Telegram Stars payment
└── HapticFeedback, MainButton, BackButton controls
↓
Bot backend processes actions
↓
Response via Bot API → Telegram clientTON integration: Mini Apps can trigger TON blockchain transactions via TON Connect, making them the entry point for Telegram's Web3 ecosystem. Since February 2025, TON is the exclusive blockchain for all Telegram Mini Apps — all apps must use TON Connect for payments and blockchain interactions.
Scale that proves the model:
Hamster Kombat: peaked at 300M users
Notcoin: 35M+ users, became a top-traded token
BotFather: 7.3M MAU in early 2026
💡 My Take: Mini Apps are the most important product development in Telegram's history since Channels. They turn Telegram from a communications platform into an operating system. A Mini App has access to the user's Telegram identity (verified, no fake accounts), payment infrastructure (Telegram Stars, TON), and a billion-user distribution channel. That's a better developer proposition than the early iPhone App Store. The PM who understands this architecture can build the next Hamster Kombat.
5️⃣ Security, Encryption & Secret Chats
Telegram's encryption architecture is genuinely sophisticated — and genuinely misunderstood.
Two Encryption Models
Cloud chats (default) | Secret chats (opt-in) | |
|---|---|---|
Encryption type | Server-client | End-to-end |
Key holder | Telegram | Only the two devices |
Multi-device | Yes (all devices) | No (specific device pair) |
Cloud backup | Yes | No |
Forward secrecy | No | Yes (key renegotiation) |
Self-destruct timers | No | Yes |
Bot access | Possible (in groups) | Impossible |
Search | Full cloud search | Device-local only |
MTProto 2.0 Encryption Details
Two-Factor Authentication (2FA)
Telegram uses phone number + SMS code as the primary auth factor. 2FA adds a cloud password (hashed with SRP — Secure Remote Password protocol) that doesn't require transmitting the actual password to the server.
💡 My Take: The honest security take on Telegram is this: cloud chats are secure against external attackers (your messages are encrypted in transit and at rest), but NOT secure against Telegram itself. Telegram CAN read your cloud chat messages if compelled. Secret Chats ARE genuinely E2E and even Telegram cannot read them. For most users — personal communication, news channels, bots — cloud chats are more than sufficient. For journalists, activists, or anyone with a real adversary, Secret Chats are the right choice. The PM who makes this trade-off explicit builds a better product than one who either oversells or undersells Telegram's security.
💾 Storage Layer: The Database Decisions
Data Type | Storage System | Justification |
|---|---|---|
Messages (cloud chats) | Telegram's custom distributed KV store | High write throughput; key-value access by (chat_id, msg_id) |
User accounts & auth | Custom sharded DB + auth key store | Strong consistency required for auth |
Media files (photos, videos) | Object storage + CDN | Immutable blobs; high read throughput globally |
Channel message history | Append-only log store | Sequential reads; immutable; high fan-out |
Bot data (chat states) | Developer-hosted (external) | Telegram doesn't store bot state |
Secret chat keys | Client-side only | Never leaves device; server never sees key |
Session data | Distributed session store | Per-device, per-DC; must be fast |
Push notification tokens | Token registry per user | APNs/FCM delivery for offline users |
Mini App data | Developer-hosted | Telegram provides identity + payment; developer owns state |
TON blockchain state | TON distributed shardchain | Decentralized; not Telegram's server |
The Multi-DC Storage Problem
Telegram's 5 datacenters don't just serve routing — they each store a subset of user data. When a user is assigned DC2 (Amsterdam), their messages are primarily stored in DC2. Cross-DC messages (user on DC1 messaging user on DC2) require:
Message written to sender's home DC
Routing to recipient's home DC
Delivery notification sent to recipient's sessions
This cross-DC write path adds latency. Telegram mitigates this with a DC tunneling system: for active conversations between users on different DCs, a persistent tunnel is maintained between DCs to minimize per-message handshake overhead.
Telegram Stars
Telegram's in-app currency launched in 2024. Stars can be used to:
Pay for Mini App goods and services
Tip channel posts and bots
Unlock premium bot features
Paid media (locked photos/videos that require Stars to view)
Architecture: Stars are a ledger system managed by Telegram's payment servers. When a user buys Stars (via App Store/Play Store), a Stars balance is credited. Stars transactions are atomic — the debit and credit happen in one operation. Stars can be converted to TON or withdrawn by creators.
TON Blockchain Integration
Since February 2025, TON is the exclusive blockchain for all Telegram Mini Apps. The integration means:
TON Connect provides one-click wallet authentication (Telegram identity = TON wallet identity)
In-chat USDT transfers via TON blockchain
Fragment marketplace for @usernames and virtual phone numbers built on TON
Channel monetization via Toncoin ad revenue sharing
Architecture impact: Telegram runs a hybrid system — centralized messaging infrastructure + decentralized blockchain settlement layer. Messages flow through Telegram's MTProto servers. Payments and token ownership flow through the TON chain. The two systems intersect at the Mini App JavaScript bridge, where a Mini App can both read Telegram user data and initiate TON transactions.
AI Integration (2025)
Telegram is integrating AI capabilities via its partnership with Cocoon (Confidential Compute Open Network on TON):
Message translation: lightweight AI operations already routed through Cocoon
Message summarization for large channels
Heavier workloads (media processing, conversational assistants) planned
The answer that wins interviews:
"Telegram's most important architectural decision isn't MTProto — it's storing messages in the cloud by default instead of using E2E encryption. That single decision enables multi-device sync, searchable history, bots reading group messages, and the Mini App ecosystem. The entire platform economy — 1.2 billion bot interactions/month, Mini Apps with 500M users, TON blockchain integration — only exists because Telegram made messages accessible to server-side processing. WhatsApp and Signal made the opposite choice and have a fraction of Telegram's platform capabilities as a result. Neither is wrong. They're different product philosophies with profound architectural consequences."
Telegram Interview Questions
Q: What's the biggest architectural difference between Telegram and WhatsApp?
Default encryption model. WhatsApp uses E2E encryption by default — messages are only decrypted on sender and recipient devices, WhatsApp cannot read them. Telegram uses server-client encryption by default — messages are stored in Telegram's cloud, readable by Telegram. This makes WhatsApp more private and Telegram more capable. Multi-device, bots, searchable history, Mini Apps, and channel broadcasting all depend on Telegram's cloud architecture.
Q: Why did Telegram build MTProto instead of using WebSockets?
WebSockets would have worked but MTProto is significantly more efficient. MTProto uses binary serialization (TL format) vs. JSON, multiplexes multiple requests over one connection, maintains session state at the server so reconnections are instantaneous, and handles network unreliability gracefully on mobile. The performance difference is most visible on 2G/3G networks in emerging markets — the primary growth markets for Telegram in 2024–2025.
Q: How does Telegram handle a channel with 100 million subscribers?
Through a tiered fan-out: active users (online when post is made) receive an immediate push via their existing MTProto connection. Offline users receive a push notification (APNs/FCM) and the message is held in the channel's append-only log. When an offline user reconnects, they pull missing messages from the channel store. For very large channels, the fan-out to active users is processed by a dedicated fleet of fan-out workers in batches — eventual consistency is acceptable because a few seconds of lag in channel delivery is imperceptible to users.
Q: What happens architecturally when a message is sent to a user on a different datacenter?
Cross-DC routing: the message is written to the sender's home DC, then a routing layer determines the recipient's home DC and forwards the message. The recipient's DC stores the message and fans it out to the recipient's active sessions. This adds approximately 100–200ms of additional latency vs. same-DC delivery. For users who frequently communicate cross-DC, Telegram maintains persistent DC-to-DC tunnels to reduce per-message overhead.
Q: How does Secret Chat E2E encryption differ from cloud chat encryption?
Cloud chats use server-client encryption: messages are encrypted between client and server using keys Telegram holds. Telegram can decrypt them. Secret Chats use device-to-device E2E: a Diffie-Hellman key exchange happens between the two specific devices (never touching the server), a shared secret is established, and each message is encrypted with a key derived from that secret plus a sequence counter (providing perfect forward secrecy). Telegram's servers only ever see ciphertext for Secret Chats and cannot decrypt them.
Q: How do Telegram Mini Apps work technically?
Mini Apps are web apps (HTML/CSS/JS) that run in Telegram's built-in WebView. They communicate with the Telegram client via a JavaScript bridge (window.Telegram.WebApp). The bridge provides verified user identity (Telegram ID, name, signed with auth key — so developers can trust it), theme data, payment initiation (Telegram Stars, TON Connect), and UI controls (back button, main button, haptic feedback). The Mini App's backend is hosted by the developer; Telegram provides identity, payments, and distribution. Since February 2025, all Mini App blockchain interactions must go through TON Connect.
💡 The Honest Take
Telegram's architecture is the most misunderstood in tech. Most people either dismiss it ("it's not truly secure") or oversell it ("it's the most secure messenger"). Both are wrong.
Telegram made deliberate product decisions at every layer:
Build your own protocol (MTProto) → won on performance in emerging markets
Store messages in cloud by default → won on utility, multi-device, and platform capabilities
Make E2E opt-in (Secret Chats) → preserved security for users who need it without sacrificing features for everyone else
Open the Bot API → created an ecosystem that now handles 1.2B interactions/month
Integrate TON blockchain → turned a messaging app into the world's fastest-growing super-app platform
Every one of these was a product decision before it was an engineering decision. Understanding them is what separates a PM who can describe Telegram's architecture from one who can design it.
That's the difference between a PM who can talk about system design and one who thinks in it. 🚀
📬 Found this useful? AI PM Insider publishes every week for AI PMs and leaders building at the frontier. This is Part 4 of the Core System Design & AI System Design series. Join at aiskillshub.io
Written by Ashima Malik · LinkedIn
Comments via Linked Groups