Telegram's Technical Anatomy: MTProto and Distributed Server Architecture

Since its launch in 2013, Telegram has become one of the most debated messaging infrastructures in the technical community. Its custom-built encryption protocol MTProto and multi-datacenter architecture have attracted both admiration and criticism. This article sets aside the debate and examines how Telegram actually works from an engineering perspective.

MTProto: A Protocol Built from Scratch

Most messaging applications work by combining existing encryption and transport layers — TLS, XMPP, Signal Protocol. Telegram instead developed MTProto (Mobile Transport Protocol), a protocol stack designed entirely from scratch.

MTProto's primary goal was low-latency operation even on slow or unstable mobile connections. To achieve this, the protocol uses a three-layer structure:

High-Level Component: Converts API queries and responses into binary format using its own serialization language called TL (Type Language). Far more compact than JSON, this format provides a noticeable advantage especially under low bandwidth conditions.

Cryptographic Layer: Establishes session keys via RSA-2048-encrypted Diffie-Hellman exchange. Messages are encrypted with AES-256, but rather than standard CBC or GCM modes, Telegram uses IGE (Infinite Garble Extension) mode — a choice that continues to generate debate in the cryptography community.

Transport Layer: Can operate over TCP, UDP, or HTTP. In censorship scenarios, the protocol can disguise itself to produce packets resembling regular HTTP/HTTPS traffic (obfuscation).

Data Centers: Five Regions, One Network

Telegram assigns users to one of five DC (Data Center) regions based on geographic location:

• DC1, DC3: Miami, USA
• DC2, DC4: Amsterdam, Netherlands
• DC5: Singapore

A user's messages always pass through their assigned DC. If two users are on different DCs, Telegram's backbone network relays the message from the source DC to the destination DC. This architecture simplifies central coordination for large group communications — but also means Telegram's servers require access to cloud messages.

On cellular connections, this works as follows: the device opens a TCP connection to the nearest DC. When TCP is used, MTProto manages its own flow control. When UDP is used, MTProto activates its own reliable delivery layer — lost packets are retransmitted at the protocol level.

Cloud Messages and Secret Chats: Two Distinct Models

Telegram's encryption model operates in two modes, and this distinction is critically important:

Cloud Messages (Default)

Regular chats, group messages, and channels use server-side encryption. Messages are stored encrypted on Telegram's servers; Telegram can technically access this content. The advantage is seamless synchronization across all devices — chat history loads instantly on a new device because the data is stored in the cloud.

Secret Chats

Only in this mode does end-to-end encryption apply. Keys exist only on the two devices involved; servers cannot access message content. Secret chats are device-specific: they cannot be accessed from another device and are not backed up to the cloud. Optional self-destruct timers apply exclusively in this mode.

This distinction represents the fundamental difference from WhatsApp and Signal: on Telegram, encryption is an opt-in feature, not the default.

Channel and Group Architecture: Millions of Simultaneous Recipients

One of Telegram's most distinctive engineering contributions is how it scales large channel delivery. A channel can contain millions of subscribers, and every new message must be delivered to all of them.

To solve this problem, Telegram uses a fan-out architecture: when a message reaches the DC, the server layer sends a push notification to the TCP session of each active subscriber. For offline users, the message is queued for delivery at the next connection.

From a cellular network perspective, the data load is proportional to an individual's connection quality — not to the number of subscribers. Each user pulls only their own incoming messages.

Media and CDN Layer

For photo, video, and file sharing, Telegram operates its own CDN infrastructure. For large channel broadcasts, dedicated CDN DCs (caching servers) come into play: popular content is served from CDN nodes geographically close to the user.

Media encryption occurs client-side at the time of upload. The encrypted payload that reaches the server is distributed to the CDN; the decryption key travels within the message. In Secret Chats, this key also passes through the end-to-end encrypted channel.

Bot API: The Programmable Face of the Messaging Infrastructure

Telegram's Bot API is the HTTP/JSON interface layer of the protocol. Bots receive events via long polling or webhooks. This infrastructure transforms Telegram from a messaging application into an integration platform.

From a cellular network perspective: when a bot webhook is triggered, Telegram's servers send a POST request to the configured HTTPS endpoint. If the request fails, Telegram retries with exponential backoff.

MTProto Behavior on Cellular Connections

MTProto is specifically optimized for mobile network conditions:

• During network transitions: When switching from Wi-Fi to cellular, the protocol attempts to reuse the existing session, reducing reconnection time.
• Under high latency: The protocol can pipeline multiple requests without waiting for responses.
• Under packet loss: In UDP mode, MTProto manages its own ACK mechanism; lost packets are detected at the application layer and re-requested.
• Under bandwidth constraints: TL serialization reduces messages to the most compact binary format possible.

Performance: A Numerical Framework

Text message latency over MTProto on good cellular connections typically falls between 30-150 ms. The occasionally lower latency observed compared to WhatsApp is primarily because MTProto is designed to minimize TCP handshakes and TLS negotiations.

However, this advantage comes at a security cost: some of the guarantees provided by widely-audited protocols like TLS are traded away.

Conclusion

Telegram took an unconventional path in messaging infrastructure design: rather than combining existing components, it wrote its own protocol end-to-end. This choice delivers concrete advantages in scale and performance, while the decisions made in the encryption model remain an ongoing discussion in the technical community. Telegram is an infrastructure that rewards understanding — one best used with clear awareness of both its strengths and its limitations.