How WeChat Achieved Real‑Time, Lossless Messaging: Inside Its Early Architecture

Background

WeChat, launched in 2011, grew to 1.34 billion monthly active users by 2023. Its early backend was built on an email‑style storage‑forward model, inheriting many design principles from the QQMail team. The system needed to satisfy two core requirements for an instant‑messaging app: messages must be delivered as close to real‑time as possible, and no messages should be lost.

Message Sending Architecture

The sending flow can be divided into two parts:

Phone A sends a message request to the access layer ConnectSvr, which forwards it to the logic layer SendSvr. SendSvr performs spam checks, blacklist filtering, etc., then stores the message in the storage layer MsgStore.

The server notifies Phone B via several steps: SendSvr sends a new‑message notification to PushSvr; PushSvr looks up the long‑connection ConnectSvr for Phone B and pushes a notification; if the long‑connection is closed (e.g., iOS background termination), PushSvr also uses the platform’s native push service (APNs, WPPush, BBPush, etc.) to deliver the tip; finally, ConnectSvr delivers the notification through the existing long‑connection.

These steps ensure that a message sent from Phone A reaches Phone B within roughly 100 ms under normal conditions.

Message Receiving Architecture

When Phone B receives the new‑message notification, it retrieves the actual message in three steps:

Phone B requests the message from ConnectSvr. ConnectSvr forwards the request to the logic layer ReceiveSvr. ReceiveSvr fetches the pending message from MsgStore and returns it to Phone B.

Message Loss‑Prevention Mechanism

Simply acknowledging every received message would generate excessive traffic and still fail under poor network conditions. Instead, WeChat introduced a sequence mechanism:

Each user has a 32‑bit sequence space (1 to UINT_MAX) allocated sequentially.

Every outgoing message receives a unique sequence number.

The server stores the highest sequence number assigned to each user.

The client stores the highest sequence number it has successfully received.

Sequence Confirmation Process

With both sides tracking their sequence numbers, the server can compute the gap and deliver only the missing range. If a server response is lost, the client will retry after a timeout, using its stored sequence to request the same range again, guaranteeing eventual delivery. The mechanism also supports multiple devices: the server records the maximum confirmed sequence, preventing duplicate delivery when a user logs in on another device.

Examples illustrate how a client with Seq_cli = 100 retrieves messages up to Seq_svr = 150, updates its local sequence to 150, and later fetches the next range when the server advances to 200. If the user switches devices, the new device receives only the unseen range, ensuring no message is missed.

Summary

The described architecture satisfied the two fundamental instant‑messaging requirements: near‑real‑time delivery and zero message loss, even on weak networks. Although WeChat’s modern stack has evolved, the early design showcases valuable principles for building scalable, reliable messaging systems.