Every day, Telegram moves an almost unreasonable amount of traffic. Voice notes, group chats with hundreds of thousands of members, 2GB file transfers, and channels broadcasting to millions of subscribers at the same second a message is sent. And yet the app rarely feels slow. Messages land in under a second whether you're in Dhaka or Düsseldorf.
The interesting part isn't that Telegram scaled; plenty of apps scale. The interesting part is how little it looks like everyone else's playbook. No Kubernetes fleet of microservices. No AWS. Not even, for most of its life, a conventional database you'd recognise from a systems design interview. Telegram's founders built almost the entire stack themselves, from the wire protocol up, and that decision is the reason the system behaves the way it does under load.
This piece is a walk-through of the actual architecture — the data centre layout, the custom protocol, the way messages are routed, and the handful of engineering decisions that let a lean team run infrastructure at the scale of a small country's population.
The Scale Problem, Stated Plainly
Before getting into the "how", it's worth being precise about the "what". At Telegram's scale, the challenges aren't just about serving requests. They're about:
Keeping a message delivered in order, even when the sender and 8 recipients are all on different continents and different networks
Doing this without losing a single message, ever, even if a data centre goes dark mid-conversation
Supporting group chats that behave more like broadcast systems (channels with millions of subscribers) alongside intimate 1-on-1 chats, using the same backend
Serving all of this cheaply enough that the product can stay free
Most companies solve a version of this with horizontal scaling behind a load balancer and a managed database with read replicas. Telegram's problem is a layer harder, because a "user" isn't just a row in a table — a user is a live, addressable entity that other users need to reach in real time, from anywhere in the world, at any time.
Decision One: Throw Out the Standard Stack
Telegram's backend is written almost entirely in C++, and it does not run on commodity cloud infrastructure. Pavel Durov and Nikolai Durov have talked publicly about this choice, and it comes down to a fairly blunt engineering argument: generic tools are built to be good at everything, which means they're rarely great at the one thing you actually need.
So instead of MySQL, Postgres, or a managed NoSQL service, Telegram built its own distributed data storage layer in-house. Instead of a REST/HTTP API, it built its own transport and encryption protocol, called MTProto. Instead of leasing capacity from a cloud provider, Telegram owns and operates its own data centres, spread across multiple legal jurisdictions specifically so that no single government or provider can compel access to the whole system at once.
This is expensive to build and maintain. It's also the reason Telegram can run at this scale with an engineering team that, for years, numbered in the dozens rather than the thousands. When you own every layer, you can optimise every layer for exactly one workload: messaging.
The Data Centre Web and the Idea of a "Home DC"
Telegram runs multiple data centre clusters positioned around the world — historically clustered around regions like Western Europe, Southeast Asia, and the Americas. Every user account is assigned a home data centre: the DC that owns the authoritative copy of that user's data (messages, contacts, media metadata, and settings).
Here's the part that matters for performance: your home DC doesn't have to be geographically close to you, and it usually doesn't need to be, because of how the network is designed underneath it.
When your app makes a connection, it connects to the nearest DC, not necessarily your home DC.
The nearest DC acts as a fast entry point and relay. If it's not your home DC, it forwards the request onwards over Telegram's own backbone network between data centres, which is a much faster and more optimised path than the public internet.
Your data is also replicated across multiple DCs, so read operations often don't need to reach all the way back to your home DC at all.
This is a meaningfully different design from "pick the closest region and serve everything from there. " It decouples where you connect from where your data lives, which is what lets Telegram avoid the classic failure mode of regional outages taking down a whole user base.
MTProto: Skipping HTTP Entirely
Most consumer apps ride on top of HTTPS. Telegram built its own protocol, MTProto, which handles both transport and end-to-end-capable encryption for its Secret Chats, as well as the standard client-server encryption used for regular cloud chats.
A few design choices in MTProto are directly aimed at scale and unreliable networks, not just security:
Binary, compact serialisation. Messages are packed into a dense binary format rather than verbose text like JSON, which matters when you're moving billions of small payloads a day.
Multiplexed queries over a single connection. A client can fire off several requests without waiting for each response in turn, and the protocol handles matching responses back to requests. This matters enormously on flaky mobile networks, where round-trip latency is the enemy.
Built-in support for switching transports (TCP, HTTP, even obfuscated transports in restrictive network environments) without the application layer caring which one is active.
None of this is exotic cryptography. What Telegram buys is a protocol tuned specifically for "lots of small, bursty messages from unreliable mobile connections", instead of a general-purpose protocol tuned for "loading web pages".
No Single Point of Failure by Construction
A detail that's easy to skim past: Telegram's data replication isn't just for durability; it's structural to how the whole system tolerates failure. Because a user's data lives across more than one DC, and DCs can serve requests for users whose home is elsewhere, the loss of any single data centre doesn't mean the loss of any user's access. Requests simply get rerouted.
This is the same principle behind Telegram's public claim of never having gone down for a significant, widespread outage in most regions at once — not because any one machine is invincible, but because the architecture assumes machines and even entire data centres will fail and routes around that assumption by default rather than treating it as an edge case.
Group Chats and Channels: Same Backend, Very Different Shape
A 3-person group chat and a channel with 5 million subscribers are conceptually opposite problems. One is small and needs low latency for a handful of participants. The other is a fan-out problem: one write needs to eventually reach millions of read replicas of "Did anything change?"
Telegram handles this with an update sequence model rather than pushing full message payloads to every subscriber synchronously. Each user has a running sequence number (referred to internally as pts a —point state, in Telegram's own terminology from its published API documentation). When something changes — a new message, an edited message, a reaction — the server doesn't blast the full content to every client immediately in a heavy synchronous operation. It increments the relevant sequence counters and pushes a lightweight update. Clients then pull the associated content, often already sitting in a nearby cache or DC, when they're ready to render it.
This separation – notifying that something changed vs. fetching the thing that changed – is what allows a broadcast channel with millions of subscribers to not behave as millions of individual synchronous message sends. It's closer in spirit to how CDNs and cache-invalidation systems work than to a naive chat-fanout implementation.
Media at Scale: Files Don't Live Where Messages Do
Photos, videos, voice notes, and documents are handled by a separate storage and delivery path from the messaging metadata itself. Media is chunked, distributed, and served from edge locations close to the requesting user, rather than being pulled from a single origin every time. This is conceptually similar to how any large-scale CDN works, but it's worth calling out because it's a deliberate separation: the "hot path" of sending a text message never has to wait on the "heavy path" of a 2GB video upload finishing replication.
The Small Team Behind It
It's genuinely one of the more remarkable facts in this whole story: Telegram scaled to hundreds of millions, then close to a billion users, with an engineering org that stayed lean for most of its growth curve. That's only possible because of the architectural choices above, not despite them. A custom, narrow, deeply understood stack needs fewer people to operate than a sprawling collection of managed third-party services, each with its own operational quirks, upgrade cycles, and failure modes.
There's a lesson in there that generalises past Telegram: horizontal team scaling and horizontal infrastructure scaling are often treated as the same problem, but they're not. Sometimes the fastest way to serve more users isn't more people — it's fewer, better-understood moving parts.
What This Means If You're Building Your Own System
You're probably not building the next Telegram, and you almost certainly shouldn't roll your own transport protocol for a SaaS product with a few thousand users. But a few of the underlying principles scale down surprisingly well:
Decouple "where you connect" from "where your data lives". Even at a small scale, this is the difference between a system that degrades gracefully during a regional outage and one that doesn't.
Separate notification from content. A lightweight "something changed" signal, with clients pulling the actual payload, avoids doing the most expensive work synchronously and repeatedly.
Don't reach for a fully custom stack until a generic one has actually failed you. Telegram's decision made sense at their scale and threat model. At most companies' scale, that same decision would be a very expensive way to reinvent things that already work.
The real takeaway isn't "build your own database". It's that every piece of Telegram's stack was chosen because the team understood their workload precisely enough to know exactly where the generic tools would break under it – and then built the narrowest possible replacement for just that piece.