Our daily lives are inseparable from WeChat. WeChat has essentially become an integral part of life in China.

However, certain aspects of WeChat’s functionality often seem strange. For example:

  • WeChat was nearly the first app to require scanning a QR code on a phone to log in on the PC client
  • WeChat group chats and chat history fail to sync completely after switching devices
  • You cannot determine whether you have been blocked by a WeChat friend
  • You cannot log in to WeChat on multiple mobile devices simultaneously

From a product perspective, these design choices appear to create obstacles for users and have become common points of criticism against WeChat. So why does the WeChat team design it this way, and why don’t they improve the user experience? I suspect the issue is not merely about product design and requirement analysis, but requires a deeper exploration of the underlying architectural essence.

While living in Australia, I discovered an interesting fact: when I sent a WeChat message to a friend also in Australia, they received it almost instantly. If WeChat operated a single centralized server in China, such performance would be insufficient to support communication within Australia. Data traveling from Australia to China and back would take at least 500ms. Yet the observed performance suggests that delivering a single WeChat message took only about 30ms.

This implies that the message likely never traveled to China at all, but was sent and received entirely within Australia. WeChat has dedicated compute nodes deployed locally in Australia. From this perspective, WeChat’s servers must be distributed globally, with no centralized server. WeChat is a distributed application.

If WeChat is indeed a distributed application, the phenomena mentioned above become easier to explain. However, to validate this hypothesis, I must establish a complete feasibility verification that satisfies all existing WeChat use cases; only then can I be confident that my conjecture is correct. To support full distributed communication, WeChat must design at least three algorithms:

  • Server selection algorithm
  • Server-side switching algorithm
  • User discovery algorithm

Of these three, the server selection algorithm allows a WeChat mobile app to locate the most suitable WeChat server. The server-side switching algorithm enables a smooth migration to a new server when the original one becomes unavailable, while maintaining message continuity. The user discovery algorithm identifies the server where the target user is located. Once these three algorithms are fully established, a user can directly locate the target WeChat server they need to connect to. The target WeChat server also knows which server hosts the intended recipient, enabling direct peer-to-peer communication between the two servers.

Server Selection Algorithm

To facilitate scalability, WeChat's servers may be deployed extensively across various locations worldwide, ensuring that any user, regardless of their geographic location, has a WeChat server that is not too far away available for connection. However, even if this is guaranteed at the hardware level, how can users at a target node learn the IP address and other details of this nearby server, and how do they know that this is the most suitable server? The server selection algorithm must first include a mechanism for server registration and discovery. In the absence of a central node, a common approach to maintaining shared data is to use the gossip protocol.

The gossip protocol is an information exchange protocol built on the principle of epidemic spread. Its concept is to imagine the information we need to propagate as a virus with an R0 > 1, meaning that each infected individual can, on average, transmit it to more than one other individual. Over time, this ensures that all individuals become "infected" with the information. The advantage of this protocol lies in its decentralized, distributed nature, which can resolve state consistency issues within a cluster. In other words, if WeChat maintains a "list of available WeChat servers," then each newly added server can broadcast its information to the cluster. This information will quickly "infect" all WeChat servers, ensuring eventual data consistency. Ultimately, every WeChat server will have access to the complete list of available servers. This technology is also widely applied in the propagation of DNS records.

For example, if WeChat uses the gossip protocol to maintain a server list, a device only needs to query any single server to obtain the full list. Based on the device's IP address, it can easily determine its geographic location (country and province) and filter the list to show servers within that province. By then measuring the speed of these servers or identifying the one with the lowest number of active connections, the device can determine the optimal WeChat server for the WeChat App to connect to.

Server-side Switching Algorithm

After selecting a server, we must also consider the possibility that the target server itself might fail, or that WeChat might decommission a server. If WeChat does decommission a server, server selection must be immediately re-executed. In this case, the app can no longer connect to the decommissioned server but will instead connect to another available, healthy server.

Of course, beyond these two scenarios, I have personally experienced a situation like this: I flew from Beijing to Singapore. My phone was powered off for the entire flight. Upon arriving in Singapore, I connected to the local LTE network and immediately launched WeChat, only to find a large number of unread messages from various people. This may seem like an ordinary occurrence, but upon closer reflection: suppose that after launching WeChat in Singapore, the app detects that the latency to my original Beijing WeChat server is unacceptably high, thereby triggering the server selection algorithm. After the server is re-selected, I quickly determine that I should connect to the Singapore server. However, WeChat messages are not broadcast across the entire distributed cluster; the Singapore WeChat server actually has no knowledge of my unread messages. Therefore, a server-side switching algorithm is required to synchronize my unread messages from the Beijing server to the Singapore server.

For example, if I performed a factory reset on my phone while on the plane, and my phone has no record of which server I was previously connected to (i.e., the Beijing server), this server switching algorithm must allow the Singapore server to autonomously determine which server the user was connected to before the switch, and then attempt to pull the message history from that original server.

In distributed systems, isn't gossip the most typical algorithm for achieving eventual consistency of data across the entire compute cluster? We can easily use gossip to propagate the key-value pair "which server a user is on" across the entire cluster. The Singapore server likely already knew I was a Beijing user before I even landed. When I connect to it, it can simply fetch my unread message history from the Beijing server and push it to my phone, and that’s all there is to it.

User Discovery Algorithm

So there is one last question remaining: while I am on a flight, when my friends and relatives send me WeChat messages, how do they know which server I am connected to? Naturally, this question is not difficult to answer. Each of my friends and relatives, just like me, uses the same WeChat client and must rely on the server selection algorithm to connect to a server that is relatively close to them, such as the Shanghai server. The user-server key-value pair has already been broadcast across the entire WeChat cluster. Before my plane lands, they will always first send the message to the Shanghai server. The Shanghai server finds that there is no "Anduin" locally, that "Anduin" is registered in Beijing, and then immediately forwards the message to the Beijing server. At this point, the Shanghai server does not need to store this message at all. For it, it is merely a relay node. The Beijing server only needs to temporarily store the message. After pushing it to my mobile app, it no longer needs to keep the message either.

As soon as my flight lands, my WeChat app first triggers the server selection algorithm and chooses Singapore. The local WeChat server in Singapore notices that a user registered in Beijing has connected to the Singapore server, and immediately triggers the server switching algorithm to synchronize my message history. At this point, the Beijing server can delete these message history records.

Of course, using the gossip protocol to broadcast user locations is just one of my hypotheses. If all WeChat servers form a graph-like data structure, they can certainly use routing-like algorithms to search for users. The relevant algorithm would be Dijkstra's algorithm, which can find the shortest path in a graph, and then messages can be sent along that path. However, I suspect that for the sake of design simplicity, the connections between WeChat servers are more likely point-to-point. In that case, finding a user could rely on a breadth-first search algorithm on the graph. That said, without reading the source code, I believe the gossip protocol is more likely, as it can explain more subsequent phenomena regarding WeChat. What can be said with certainty is that a single message will not be broadcast across the entire network, but will only exist between the two servers involved in sending and receiving, remaining completely unknown to all other servers.

User Login

WeChat's functionality goes beyond just sending messages. It also includes a login and registration process. We speculate that WeChat's user account management is most likely not designed to be distributed. Even with a gossip protocol, only eventual consistency can be guaranteed. However, basic user profiles and passwords are sensitive data that require higher real-time consistency and should not be stored in a distributed manner. It is more appropriate to host this data in a centralized data center. When users need to log in or register, they can simply connect directly to this central authentication gateway. The load on this gateway will not be too heavy, as nobody is going to keep switching accounts for no reason all day long.

Group Chat

Group chats also need explanation, but they are not difficult. However, before explaining group chats, we can first draw an analogy between the communication process in WeChat and the process of Email. In fact, the two are highly similar: the SMTP protocol for Email also lacks a central node. Instead, it relies on the latter part of the Email address to select the server, and the latter part of the recipient's address to locate the user. Email almost never involves switching servers. Therefore, once the servers hosting the sender and recipient are determined, the Email is sent directly between these two servers, and that's it.

In reality, we frequently send mass Emails and enjoy using "Reply All" when receiving them. This usage is actually highly similar to group chats in WeChat: chatting in a group is essentially the same as continuously using "Reply All" on a single Email, which naturally solves the requirement.

So how is leaving a group implemented? It is naturally not difficult either. After someone uses "Reply All" to include me, if I no longer wish to participate in the discussion, I would "Reply All" with the message: "Please remove me from the recipient list!" If everyone is smart enough, they will simply stop including me in future "Reply All" messages, and I will naturally stop receiving them, thus fulfilling the use case of leaving the group.

File Transfer

File transfer is even easier to explain. It's essentially analogous to the attachment feature in email. The only difference is that WeChat automatically deletes files after a few days of storage, ensuring that server space usage remains manageable.

Why Is WeChat Designed This Way?

This design offers numerous benefits. First, from an operations perspective, it truly achieves the principle of "adding capacity exactly where it is needed." Consider a scenario where a large number of users from Africa suddenly appear, but there are no WeChat nodes in Africa. When these users select a server, they might all end up choosing the node in South Africa, which is far from most of them. To improve the WeChat experience for users in Central and Northern Africa, the WeChat team can simply deploy a server in that region. Once installed, no further configuration is required. The server itself will automatically announce its existence via gossip protocols. Users in Central and Northern Africa will quickly switch to the new server the next time the server selection algorithm is triggered, significantly reducing latency.

Additionally, this design greatly reduces the criticality of any single server's lifecycle. If a few servers fail, it is not a problem for WeChat at all. Users connected to those servers will quickly re-run the server selection process and switch to other available WeChat servers. Users may not even notice the failure. Overall, this distributed application design makes WeChat behave like a telecom carrier's base station: where signal is weak, add one; where one fails, connectivity is unaffected—users might just experience temporary slowdowns.

1.5 billion people send massive volumes of WeChat messages every day. This volume would be extremely difficult for any single point of failure to handle. In China, if WeChat establishes nodes in every city, this enormous traffic is distributed across all cities. No single node experiences high load. WeChat can easily achieve horizontal scaling without even needing load balancing. This operational experience is about as good as it gets. WeChat truly achieves high user concurrency through architectural design itself, rather than relying on massive amounts of money and computational resources.

WeChat is also an international application. A significant number of foreign users rely on it. When communicating, they should not be forced to route data through a single data center in China. WeChat's design is more like telecommunications infrastructure, enabling foreigners to exchange information directly locally. Furthermore, if different regions have different laws, WeChat can simply modify the servers in that specific region. For example, if a country requires chat logs to be registered and audited, WeChat can deploy servers with audit capabilities only in that country, without adjusting the overall architecture. This change is also transparent to the app.

QQ Analogy

By comparison, QQ has full support for simultaneous logins across multiple devices, cross-device synchronization of chat history, and persistent and searchable QQ groups. It is more likely a centralized deployment, relying on powerful load balancing and operational capabilities to keep the data center running smoothly. If a single point of failure occurs, the entire global QQ service goes down. In Australia, I tried chatting on QQ, and the experience was extremely laggy—a single message would take forever to load. So, the Tencent technical team probably faced the same issues, but modifying the existing QQ infrastructure directly would have been far too cumbersome. Instead, they decided to start from scratch and develop a completely new, clean, distributed, globally scalable, and high-concurrency IM application to serve as the foundation for communication.

Given this architectural design, I have to commend the WeChat team for their exceptionally clever engineering. They leveraged a distributed network to disperse load, allowing messages to travel via the nearest path and rendering individual server lifespans less critical—wherever performance lags, capacity is simply added there. It is truly a rare example of excellent system design!

Clarifying Confusion

By now, the several challenges I raised at the beginning should be relatively easy to answer.

  • WeChat is almost the first app that requires scanning a QR code on your phone to log in to the PC client.
  • WeChat groups and chat histories are completely out of sync after switching devices.
  • You cannot tell if you have been blocked by a WeChat friend.
  • You cannot log in to WeChat on multiple mobile devices simultaneously.

Why is a phone QR code scan required to log in to the PC client? This is because if you log in to the PC client by entering a password, the server selection algorithm will run again. Once the selected server is different from the one your phone is connected to, your phone will no longer receive messages. Requiring a phone QR code scan is not to make things difficult for users, but to first determine which WeChat server your phone is connected to. After confirmation, the PC is also directed to connect to the same server, ensuring that when messages arrive, both the phone and the PC can properly send, receive, and sync. Naturally, this also explains the fourth issue: why you cannot log in to WeChat on multiple devices simultaneously. It is to ensure that, while the gossip protocol is operating, you are not registered on two different WeChat servers at the same time.

Moreover, we can observe: immediately after the PC logs in, its message history is actually synced from the phone to the PC. This is because the server does not store your chat history at all.

This also explains the second issue: why chat records are lost entirely after switching devices? The server only serves as a relay, transmission, and temporary storage function. WeChat chat records are saved entirely locally. After you switch devices, since these data do not exist locally on the new device, they are all lost. The same applies to group chats. We compared group chats to mass emailing in Email. If the Email itself has not been synced, it is naturally impossible to determine how many groups you have joined.

There is one last loophole I have not discussed: how is the WeChat friends list maintained? Since the friends list syncs properly after switching devices, it should not be stored only locally but must exist on the server. However, when you are blocked by a WeChat friend, no message is actually sent. Therefore, your local message history still contains records of messages with the friend who blocked you, just as you can still see your chat history with an Email sender who has blocked you. Naturally, this design leads to the fact that you cannot know about this. Only when you attempt to send a message and it fails can it be proven that they may no longer wish to talk to you.

To the Product Manager

Having said all that, the more one studies the essence of a subject, the more one realizes that it is actually far more complex than imagined. Yet, I still know too many product managers who blindly imitate WeChat, who mindlessly implement QR code scanning for mobile phones, and who encounter too many PMs who constantly complain about WeChat's various shortcomings, wanting to "kill" WeChat. "Isn't it just about sending a message? How hard can it be?" The answer is: Of course it is. And even in the current hypothesis regarding WeChat's protocol mentioned above, I believe there are numerous oversights and deviations from reality. Some features aren't possible because programmers are incompetent; rather, the underlying data structure itself simply cannot support them. But too many PMs fail to recognize this. A single line of their requirements might force a complete rearchitecture of the entire system.