Telegram System Design Interview: Cloud Messaging, Multi-Device Sync, and Million-Subscriber Channels
Telegram has reported more than 900 million monthly active users, and unlike WhatsApp it keeps your entire message history in the cloud so any device can open a chat and see everything. A single public channel can have millions of subscribers, so one admin tapping send can turn into a fanout to millions of delivery targets. The hard part is not the chat bubble. It is keeping every device consistent, ordering updates correctly after a client has been offline, and doing it across data centers on different continents.
Telegram is a cloud-first messenger. Cloud chats live server-side, encrypted at rest but readable by Telegram, which is what lets a brand new phone log in and instantly see full history, search, and media. This is the deliberate split from WhatsApp, which keeps the source of truth on your phone. The account is pinned to a home data center chosen at registration, and all of that user's cloud data lives there. Clients hold a persistent MTProto session and receive updates in real time. When a client reconnects after being offline, it does not replay every event. It compares its local sequence counters (pts, qts, seq) against the server and calls getDifference or getChannelDifference to fetch only the delta. Groups scale to 200,000 members and broadcast channels are effectively unlimited, so the design has to handle both tight 1:1 delivery and massive one-to-many fanout. End-to-end encryption exists only in Secret Chats, which are bound to a single device pair and never touch the cloud.
Asked at: Asked at Meta, Google, Amazon, and messaging or real-time startups. It also comes up in interviews for any team building presence, chat, or notification infrastructure.
Why this question is asked
It forces a candidate to confront the tension between convenience and privacy in a concrete way. The cloud-chat model makes multi-device sync easy but means the provider can read messages, while true end-to-end encryption breaks seamless history sync. A strong answer separates those two worlds instead of hand-waving that everything is encrypted. The problem also tests real-time delivery over persistent connections, gap recovery after a client goes offline, ordering guarantees, and the very different shapes of 1:1 delivery versus fanout to millions. There is a lot of surface area, so it rewards candidates who can structure the discussion and pick the two or three genuinely hard parts.
Requirements
Always clarify these in the first 5 minutes of the interview. Do not start drawing boxes until both lists are agreed.
Functional requirements
- Send and receive 1:1 and group messages in real time with low latency
- Sync full message history, drafts, and read state across all of a user's devices from the cloud
- Support large groups up to 200,000 members and broadcast channels with millions of subscribers
- Fan out a channel post to every subscriber and reflect it in their chat list ordering
- Store and serve media (photos, video, files up to several gigabytes) through a distributed file layer
- Show presence, typing indicators, and read receipts where the chat type allows it
- Offer optional end-to-end encrypted Secret Chats bound to a single device pair
- Recover missed updates efficiently after a client has been offline
- Support message edit and delete, reflected on every device
Non-functional requirements
- Real-time delivery latency in the low hundreds of milliseconds for online recipients
- High availability across multiple data centers with automatic failover if one region degrades
- Durability of cloud chat data with cross-region replication of both messages and encryption keys
- Correct ordering of updates per chat, with gap detection and recovery rather than silent loss
- Efficient bandwidth use on poor mobile networks, which drove the custom MTProto transport
- Horizontal scalability so groups and channels can grow without a rewrite
- Confidentiality at rest and in transit, with a clear boundary between cloud chats and Secret Chats
Back-of-envelope scale estimates
Show your math. Pulling numbers from thin air signals you have not thought about the load.
Monthly active users
~900M+ (reported)
Telegram founder Pavel Durov publicly reported crossing 900M and later 950M monthly active users. Treat any single figure as reported rather than independently audited.
Messages per day
~13B/day (Derived estimate)
If roughly 900M users each send about 15 messages per day, that is 900M x 15 = 13.5B message events per day. This is a back-of-envelope figure, not a published number.
Concurrent persistent connections
~180M (Derived estimate)
If about 20 percent of the user base is online and holding an open MTProto session at peak, that is 900M x 0.2 = 180M concurrent long-lived connections to terminate and route.
Channel fanout for a large post
millions of targets per post (estimate)
A public channel can have millions of subscribers. One send therefore updates millions of chat lists, so the write path for a single post dwarfs a 1:1 message by six orders of magnitude.
Max file size per upload
up to 4 GB (published)
Telegram documents support for individual files up to 4 GB, which is why the file layer is separated from message storage and referenced by a dc_id and file id.
Data centers
several worldwide, commonly cited as five (partly estimate)
Official docs say servers are divided into several DCs in different parts of the world without giving a count. Client libraries and secondary writeups commonly reference DC1 through DC5, so five is a widely repeated estimate, not an official number.
High-level architecture
A client opens a persistent connection to the nearest access point and speaks MTProto, Telegram's own transport and encryption protocol built for high-latency mobile networks. During registration the account is assigned a home data center, usually based on the IP address seen at sign-up, and all of that user's cloud data lives in that DC. If a client connects to the wrong DC for an operation it gets a migrate error (PHONE_MIGRATE, NETWORK_MIGRATE, or FILE_MIGRATE for files) and reconnects to the correct one. When a user sends a cloud message, it travels over the encrypted client-server channel to their home DC, which persists it, updates the per-chat sequence counter, and pushes an update to any online recipient sessions while queuing it for offline devices. Each device tracks its own view of the world through sequence counters (pts for message boxes, qts for secret and some bot events, seq for the overall update stream). When a device reconnects, it does not replay history. It sends its last known counters and calls updates.getDifference, or updates.getChannelDifference for a specific channel, and the server returns only the missing events plus the new state. Media does not flow through the message path. Files are uploaded to and downloaded from a file store addressed by dc_id, and popular media from large public channels is fronted by CDN caching nodes so a viral post does not hammer the origin DC. Secret Chats sit outside all of this: their keys are negotiated directly between two devices and the server only relays opaque ciphertext.
In a real interview, sketch this on the whiteboard before diving into any single box.
Core components
Walk through each service. The interviewer wants to hear what each one owns, not just the names.
MTProto session layer
The custom protocol that carries every request over a persistent connection. It handles authorization keys, message ids, acknowledgements, and the client-server encryption for cloud chats using AES in IGE mode with SHA-256 integrity. It was designed to stay efficient on flaky, high-latency mobile links, which is why Telegram rolled its own rather than using plain TLS framing.
Data center router and home-DC assignment
Servers are split into several DCs worldwide. A new account is pinned to a home DC at registration and its cloud data lives there. Clients discover the right DC through migrate errors and a nearestDc hint, and encryption keys are not copied between DCs, which shapes where data can be read.
Cloud message store
The server-side source of truth for cloud chats. It stores messages encrypted at rest, maintains per-chat pts sequences, and is what makes instant multi-device history, server-side search, and cloud drafts possible. This is the component that WhatsApp deliberately does not have, since WhatsApp keeps the source of truth on the phone.
Update and sync engine
Produces the ordered update stream every client consumes. It assigns pts, qts, and seq values so clients can detect duplicates and gaps, and it serves getDifference and getChannelDifference so a returning client fetches only the delta. Channels each carry their own pts, separate from the common message box, so a busy channel does not force resyncs elsewhere.
Channel and group fanout service
Handles the one-to-many write path. A supergroup can hold up to 200,000 members and a channel can have millions of subscribers, so posting is fundamentally different from a 1:1 send. The service updates the channel's pts once and lets subscribers pull the new state through getChannelDifference rather than pushing millions of individual copies synchronously.
Distributed file and media layer
Stores photos, video, and files up to 4 GB, each addressed by a dc_id and file id and encrypted with a per-file key. Direct download happens from the DC that holds the file. For popular public channels above a size threshold, CDN caching nodes serve the hot media so origin DCs are not overloaded, while private data never lands on the CDN.
Secret Chat endpoint
The end-to-end path. Keys are established with a Diffie-Hellman exchange directly between two devices, verified by comparing a key fingerprint, and the server only forwards ciphertext it cannot read. Because the key lives on the devices, a Secret Chat is bound to one device pair and its messages are never in the cloud.
Data model
Pick the right store per table. Justify each choice with the access pattern, not by reflex.
usersuser_idhome_dc_idphone_hashlast_seensettingsAccount record pinned to a home DC set at registration. last_seen backs presence, which users can restrict, so the stored value may be an approximate bucket rather than an exact timestamp.
messageschat_idmessage_idsender_iddatebody_refedit_dateCloud message rows keyed by chat and a per-chat message id. Editing a message keeps the same message_id and only bumps edit_date, which keeps ordering stable while letting clients detect the change.
chat_statechat_idchat_typeptstop_message_idmember_countPer-chat sequence state. chat_type distinguishes private, basic group, supergroup, and channel. Channels keep an independent pts so their high write rate does not disturb the common message box.
dialogsuser_idchat_idunread_countread_inbox_max_idpinneddraftOne row per user per conversation. Drives the chat list, unread badges, read receipts through read_inbox_max_id, and cloud drafts that sync across devices.
channel_subscriptionschannel_iduser_idjoined_atnotifyroleMembership edges for channels and supergroups. For a channel with millions of subscribers this is the fanout target set, and it is what makes a single post an expensive one-to-many operation.
filesfile_iddc_idsizecontent_typefile_key_refMedia metadata separate from messages. dc_id says which data center holds the bytes, and each file carries its own encryption key. Messages reference files by id rather than embedding them.
Deep dives
These are the conversations the interviewer is steering you toward. Practice each one until you can talk through it without notes.
Cloud chats versus Secret Chats, and the honest encryption story
This is the design decision that defines Telegram and the one interviewers probe. Cloud chats use client-server encryption. Messages are encrypted in transit and at rest, but Telegram holds both the ciphertext and the keys, so it can technically read them. That is a feature, not an oversight: it is precisely what lets you log in on a new device and instantly get full history, search, and media with nothing stored locally. Secret Chats are the only end-to-end encrypted text path. Their keys are generated by a Diffie-Hellman exchange between two devices, verified through a key fingerprint, and never sent to the server. The cost is that a Secret Chat lives on exactly one device pair. There is no history sync to a new phone, no server search, no cloud backup. Telegram splits its jurisdiction risk by keeping encrypted cloud data and the keys that decrypt it in different data centers, but a candidate should be clear that cloud chats are not end-to-end encrypted. Saying so plainly is what separates a credible answer from marketing.
Home data center pinning and cross-DC operations
Every account is assigned a home DC at registration, typically from the IP address at sign-up, and all of that user's cloud data lives there. This keeps a user's reads and writes local and simplifies consistency, since there is a single authoritative location for their chats. The tradeoff shows up in cross-DC interactions. A client that connects to the wrong DC receives a migrate error and has to reconnect: PHONE_MIGRATE during auth, NETWORK_MIGRATE for geography, FILE_MIGRATE when a file lives elsewhere. Because encryption keys are not copied between DCs, you cannot just read a user's data from any region. When two users on different home DCs chat, the system has to route between DCs and materialize the conversation in each participant's DC. In an interview this is a good place to discuss data locality, the latency benefit of pinning, and the operational pain of any feature that has to span DCs.
Update sync with pts, qts, seq and getDifference
Real-time messengers cannot assume a client is always online, so the interesting problem is what happens after a gap. Telegram gives each client sequence counters: pts for message-box events in private chats and basic groups, qts for secret and certain bot updates, and seq for the overall update stream. Every update carries enough information that a client can check local_pts + pts_count against the incoming pts. If they match, apply it. If the incoming value is lower, it is a duplicate and gets dropped. If it is higher, there is a gap, and the client calls updates.getDifference to fetch exactly the missing events plus the new state. Channels each carry their own pts and are recovered with updates.getChannelDifference, which means a firehose channel does not force a full resync of everything else. When the delta is too large to return at once, the server pages it with a difference-slice response. This design is why opening Telegram after a day offline is fast: the client pulls a diff, not the whole history.
Channel fanout to millions versus 1:1 delivery
A 1:1 message and a channel broadcast look similar in the UI and are completely different systems underneath. For a direct message the write path touches two dialogs. For a channel with millions of subscribers, a naive push that writes one copy per subscriber synchronously would be impossibly expensive and slow. The scalable approach is to treat the channel as a single append-only stream with its own pts. The post is written once to the channel, its pts advances, and subscribers learn about it through the update stream and getChannelDifference when they next sync, rather than through millions of individual fanout-on-write inserts. This is a fanout-on-read style choice for very large audiences, similar to how large social feeds avoid materializing a celebrity post into hundreds of millions of inboxes. Supergroups up to 200,000 members sit in between: they need per-member read state and mentions, so they cannot be quite as lazy as a broadcast channel.
Presence, typing, and read receipts at scale
Presence is deceptively expensive because it is high-frequency, low-value, and fans out to everyone who has a chat open with you. Telegram treats last-seen as privacy-sensitive and lets users hide it or show only an approximate bucket like recently or within a week, which conveniently also reduces update volume. Typing indicators are ephemeral signals with a short time to live, sent to the people currently viewing a chat and never persisted, so they can be dropped under load without correctness impact. Read receipts in 1:1 and small groups are tracked with a read_inbox_max_id watermark per dialog rather than a flag on every message, which collapses a per-message write into a single moving pointer. In very large groups and channels, per-member read receipts do not scale and are intentionally limited. The general lesson is that presence-class signals should be cheap, best-effort, and shed first when the system is stressed.
Media and the distributed file layer
Media is kept out of the message store on purpose. A message references a file by a dc_id and file id, and the bytes live in a file layer that can be downloaded directly from the DC that holds them, with each file encrypted under its own key. Uploads are chunked so large files up to 4 GB can be sent and resumed on unreliable mobile networks. The scaling risk is a viral post in a huge public channel where millions of people fetch the same photo or video at once. Telegram fronts popular media from large public channels with CDN caching nodes so those reads are served near the user and do not overload the origin DC, while making the point that private data and small chats never go to the CDN. Encrypting each file separately and keeping keys out of the CDN keeps the caching layer from becoming a data-exposure risk.
Message ordering and idempotent delivery
Users expect messages in a chat to appear in a stable order and never to see the same message twice, even though the network will duplicate and reorder packets. Telegram leans on message ids and per-chat pts rather than wall-clock time for ordering, since clocks across clients and DCs cannot be trusted. A message id is stable across edits, so editing does not reshuffle history. Delivery is made idempotent by the sequence check: because a client compares its local counters against every incoming update, a retransmitted update with a pts it has already applied is recognized as a duplicate and ignored. This is what lets the transport retry aggressively on a bad connection without producing duplicate bubbles. When ordering cannot be reconstructed from local state because too much was missed, the client falls back to getDifference and re-derives a consistent view from the server's authoritative sequence.
Trade-offs to discuss
Every senior interviewer expects you to surface at least 3 of these. Pick the decisions, state the alternatives, and justify your choice.
Cloud chats readable by the server versus end-to-end encryption everywhere
Storing cloud chats server-side gives instant multi-device sync, history on any device, and server search, at the cost of the provider being able to read them. Telegram makes E2E opt-in through Secret Chats only. WhatsApp made the opposite call and pays for it with a phone-centric, harder multi-device story.
Custom MTProto protocol versus standard TLS and HTTP
Rolling a bespoke protocol let Telegram optimize for high-latency mobile networks, connection reuse, and its own encryption model, and gave tight control over the sync semantics. The price is a protocol that had to be independently scrutinized for security and that every third-party client must reimplement.
Pinning users to a home DC versus fully geo-replicated accounts
A single home DC per account keeps a user's data consistent and local and avoids multi-master conflicts. The downside is cross-DC friction: migrate errors, the fact that keys are not copied between DCs, and extra routing when two users live in different regions.
Fanout-on-read for large channels versus fanout-on-write per subscriber
Writing a channel post once and letting subscribers pull it through getChannelDifference scales to millions of subscribers. Writing a copy per subscriber would give simpler per-user inboxes but is impossibly expensive at broadcast scale. Small chats can afford the eager path; channels cannot.
Diff-based sync (getDifference) versus pushing every event to every device
Sequence counters plus a diff call let a returning client fetch only what it missed, which is efficient for clients that go offline often. It costs more server-side bookkeeping to maintain per-chat and per-channel pts and to serve paged differences correctly.
Best-effort presence and typing versus strongly consistent status
Making last-seen approximate and typing ephemeral cuts a huge volume of low-value writes and lets those signals be dropped under load. The tradeoff is that presence is intentionally imprecise, which is acceptable for status but would not be for message delivery.
How Telegram actually does it
Telegram runs its own MTProto protocol, created by Nikolai Durov, rather than adopting an off-the-shelf messaging stack, and its public API documentation is unusually detailed about the sync model. The techfaq and encryption pages describe client-server encryption for cloud chats using AES in IGE mode with SHA-256, versus Diffie-Hellman end-to-end encryption for Secret Chats and calls. The updates documentation specifies the pts, qts, and seq counters and the getDifference and getChannelDifference recovery calls. The datacenter documentation confirms that servers are split across several DCs, that accounts are pinned by registration, that clients follow PHONE_MIGRATE, NETWORK_MIGRATE, and FILE_MIGRATE errors to the right DC, and that encryption keys are not copied between DCs. The end-to-end page documents the device-pair binding of Secret Chats, key-fingerprint verification, and rekeying for forward secrecy after roughly 100 messages or one week. User counts of 900M and later 950M monthly active users come from public statements by the founder and should be treated as reported rather than audited.
Sources
- Telegram FAQ for the Technically Inclined (encryption, CDN, files)
- Telegram API: Working with Updates (pts, qts, seq, getDifference)
- Telegram API: Working with Different Data Centers (home DC, migrate errors)
- Telegram API: End-to-End Encryption, Secret Chats
- Telegram API: Channels, supergroups, gigagroups and basic groups
Lessons to study before this interview
If any of these topics are fuzzy, the interviewer will catch it. Each lesson is 15 to 60 minutes with diagrams, code, and a quiz.
Related system design interview questions
Practice these next. They lean on the same core building blocks as Telegram.