Five data centers. That’s what Telegram publicly claims. DC1 through DC5, distributed across Miami, Amsterdam, and Singapore. But when actual users started digging into where their accounts lived, something didn’t add up. DC2 and DC3 had zero users. Zero. In a platform with hundreds of millions of active accounts, two-thirds of the infrastructure appeared to be running empty.
This is the story of what happens when you try to reverse-engineer a proprietary distributed system from the outside. It’s a tale of phantom data centers, borrowed CDN domains, and the architectural compromises that keep a billion-user messaging platform running without the safety net of open-source infrastructure.
The Five-DC Illusion
Telegram’s official story is straightforward. According to the company’s code and documentation, there are five data centers:
- DC1: Miami, USA
- DC2: Amsterdam, Netherlands
- DC3: Miami, USA
- DC4: Amsterdam, Netherlands
- DC5: Singapore
Each account is permanently pinned to one of these data centers upon registration. That assignment doesn’t change when you switch phone numbers or move to a different country. Users can’t choose their DC either, connect to the wrong one and the server spits back a PHONE_MIGRATE_X error, forcing the client to reconnect to the correct server.
But here’s where things get weird. When community members built bots to query which DC users were on, they found a pattern that made no sense. Users with +86 (China) numbers were on DC5. +1 (US) numbers landed on DC1. European numbers showed up on DC4. And DC2 and DC3? Empty. Hundreds of users checked, and not a single one belonged to those two data centers.
The immediate speculation was that DC2 and DC3 had been deprecated. But that didn’t match Telegram’s official stance. And it didn’t explain why their server infrastructure was still running.
Why Your DC Detection Method is Probably Wrong
The real answer is more subtle, and it reveals a lot about how Telegram’s infrastructure actually works. There are three common methods to determine which data center a user belongs to, and only one of them is reliable.
Method 1: The Login Protocol (Accurate)
This is the gold standard. When you attempt to register or log in, Telegram’s MTProto protocol performs a DC redirection dance. Connect to the wrong DC, and the server tells you exactly which one to use via PHONE_MIGRATE_X. This method requires knowing the phone number, making it impractical for batch queries, but it never lies.
Method 2: The Profile Picture Trick (Accurate)
Telegram stores media assets on the DC where the user is registered. When a third-party client like Plus Messenger shows a user’s DC, it’s reading the dc_id field from the userProfilePhoto MTProto structure. If you upload a profile picture and the client says you’re on DC2, you’re on DC2.
Method 3: The Web CDN Method (Flawed)
This is where the mystery starts making sense. Bots that determine DC via Telegram’s Web CDN, by checking the CDN domain used to serve profile pictures, were reporting phantom results. Here’s why: Telegram’s CDN infrastructure borrows domains across data centers in the same geographic location.
A user’s profile picture URL starts with cdnN.cdn.telegram.org, where N is the DC number. But DC2 and DC3 “borrow” the CDN domains of DC4 and DC1 respectively. So a legitimate DC2 user’s profile picture gets served from cdn4.cdn.telegram.org, making every bot that uses the Web CDN method misidentify them as DC4 users.
The bot that sparked all the speculation about DC2 and DC3 being empty was using this exact method. It never saw a DC2 user because it was looking at CDN domains, not actual data center assignments.
The Mystery of DC3
DC2, it turns out, is very much real and actively serving users. Phone numbers from Germany (+49), among other country codes, are assigned to DC2. The detection bots were just using the wrong technique.
DC3 is a different story. After extensive sleuthing using Method 2 (the profile picture approach), researchers found exactly two users who appeared to be on DC3. Even those are questionable, their old profile pictures were stored on DC3, but newly uploaded images were going to DC1. The same pattern appeared in their message history: old media on DC3, new media on DC1.
The evidence strongly suggests that DC3 was decommissioned around 2020, with its users migrated to DC1. Testing with over 10,000 randomly generated phone numbers from global regions confirmed that no new accounts are assigned to DC3. It’s a ghost data center, still operational, but running empty, a remnant of an earlier scaling strategy.
Telegram’s dependency on centralized DNS infrastructure doesn’t make this investigation any easier. When even basic domain-level infrastructure can be disrupted, understanding the underlying data center architecture becomes critical for resilience planning.
The Real DC Allocation Logic
After the investigation, the actual allocation rules became clear. Telegram assigns data centers based on the country code of the phone number provided at registration, not geographic location, not IP address:
| Country Code Region | Assigned DC | Location |
|---|---|---|
| +1 (North America) | DC1 | Miami |
| +49, +44 (Europe) | DC2 | Amsterdam |
| +86 (China) | DC5 | Singapore |
| +33, +34 (Western Europe) | DC4 | Amsterdam |
| Deprecated (migrated to DC1) | DC3 | Miami |
The allocation is not based on network latency or current location. A user with a +86 phone number living in New York is still assigned to DC5 in Singapore. This creates obvious latency problems, a Chinese expat in the US experiences Singapore-level ping times for every message. But it also creates a predictable partitioning model that simplifies data sovereignty and infrastructure management.
What This Reveals About Telegram’s Architecture
This isn’t just a trivia exercise. The DC allocation scheme reveals fundamental architectural decisions that have real implications for users and engineers.
Server-side message storage is real, and it’s per-DC. Telegram stores all non-secret chat messages on the server, organized by data center. This is what enables seamless multi-device syncing, your message history follows you across phones, desktops, and tablets without needing local backup. But it also means your data physically resides in a specific geographic location determined by the country code of the phone number you used to register.
The DC is a shard key. For a distributed system serving a billion users, sharding is essential. Telegram’s approach is primitive compared to modern distributed databases, hard-partition by phone country code into five fixed shards, but it works because the shard assignment never changes. No rebalancing, no hot partition migration, no complex consistent hashing. Just a static lookup table.
This simplicity has trade-offs. DC5’s notorious instability is well-documented in the Telegram community. When DC5 goes down, which happens frequently enough to be a running joke, every user assigned to that DC loses access completely. They can’t fail over to DC1 or DC4 because their data doesn’t exist there. This is the cost of static sharding without replication across regions.
The DC3 “ghost” suggests infrastructure is retired, not reused. Rather than repurposing DC3’s hardware for new users, Telegram appears to have simply stopped assigning accounts to it while keeping the servers running. In a world where cloud infrastructure costs are a primary driver, maintaining an empty data center is a strangely expensive choice, unless the hardware was already owned and the operational overhead of decommissioning exceeded the power savings.
The Data Sovereignty Angle
Telegram’s DC allocation has increasingly important implications as regulatory pressure mounts. Following Pavel Durov’s arrest in France in August 2024, and the ongoing legal proceedings, the question of where user data actually resides has become central to privacy and compliance debates.
Because Telegram assigns DC based on phone country code, a user with a French phone number (+33) ends up on DC4 in Amsterdam, not in France. This matters for GDPR enforcement, data access requests, and the ongoing tension between European regulators and Telegram’s privacy model. The platform’s unique architecture means that a French user’s data is stored in the Netherlands, under Dutch jurisdiction, operated by a company headquartered in Dubai and incorporated in the British Virgin Islands.
This jurisdictional complexity isn’t an accident. Nikolai Durov designed the MTProto protocol and the underlying infrastructure specifically to minimize the ability of any single government to compel data access. The distributed architecture is a feature, not a bug, even if it means DC5 users suffer regular outages.
What Engineers Can Learn From Telegram’s Approach
For all the criticism Telegram’s architecture receives, and there’s plenty, there are genuine lessons here for anyone building distributed systems at scale.
Static sharding isn’t always wrong. Modern distributed systems dogma favors dynamic rebalancing, consistent hashing, and automated failover. Telegram’s approach is the anti-pattern: five fixed shards, manually assigned, with no cross-region replication. But it’s remarkably simple to reason about, debug, and operate with a team estimated at fewer than 100 employees. Complexity has a real cost, and Telegram’s architecture optimizes for operational simplicity over theoretical elegance.
Minimize state changes. The decision to pin users to a single DC permanently eliminates an entire class of distributed systems problems. No need for leader election, no split-brain scenarios, no consistency guarantees across regions. The trade-off is that users in Singapore get suboptimal latency when communicating with users in Amsterdam, but Telegram presumably decided that was acceptable.
Proprietary infrastructure gives you freedom. Because Telegram doesn’t run on AWS or GCP, they control their entire stack. This means they can do things like borrow CDN domains across data centers (as with DC2 and DC4) without worrying about vendor limitations. It also means debugging requires reverse-engineering from the outside, but for the engineers running the system, it’s fully understood.
Telegram’s five data centers are real, but the map doesn’t match the territory. DC2 serves real users in Europe. DC3 is a ghost, its users long migrated to DC1, its hardware still humming in a Miami data center for reasons only Pavel Durov fully understands. And the tools you use to detect your DC might be lying to you, because Telegram’s CDN abstraction layer intentionally obscures the underlying infrastructure.
The real lesson is that Telegram’s architecture, for all its quirks, outages, and unexplained artifacts, works. It serves a billion users with a fraction of the engineering headcount that Meta or Google would commit to a similar service. The static sharding, the opaque DC allocation, the phantom data centers, the CDN domain borrowing: all of it is held together by proprietary knowledge that exists only in the heads of Nikolai Durov and a tiny team of engineers. That’s either terrifying or impressive, depending on whether your DC5 session is currently reconnecting.
For engineers building distributed systems, the lesson is clear: architectural purity matters less than operational simplicity. Telegram’s approach wouldn’t pass a systems design interview at FAANG, but it powers one of the most-used applications on the planet. Sometimes the best architecture is the one you can actually operate.
