WeChat Message Sending and Receiving Architecture (2014)

In 2023, WeChat reached 1.34 billion monthly active users, and its underlying technology has evolved significantly since its launch in 2011. This article revisits the early architecture of WeChat’s messaging system, focusing on how messages are sent, received, and protected against loss.

Background : WeChat originated from the QQMail team, and its initial backend architecture inherited many concepts from email systems, especially the storage‑forward mechanism.

The instant‑messaging requirements are twofold: (1) messages should be delivered in real time, and (2) no messages should be lost.

Message Sending Architecture (Figure 1):

Phone A sends a request to the access layer ConnectSvr .

ConnectSvr forwards the request to the logic layer SendSvr .

SendSvr performs business logic (spam filtering, blacklist checks, etc.) and stores the message in MsgStore .

The logic layer notifies the push layer PushSvr that a new message is ready for Phone B.

PushSvr looks up the long‑connection server ( ConnectSvr ) that holds Phone B’s connection and forwards the notification.

If the long‑connection is unavailable (e.g., iOS background termination), PushSvr sends a push tip to the platform’s third‑party push service (APNs, WPPush, BBPush, etc.).

The long‑connection server finally pushes the notification to Phone B.

Message Receiving Architecture (Figure 2):

Phone B initiates a request to ConnectSvr to fetch new messages.

ConnectSvr forwards the request to the logic layer ReceiveSvr .

ReceiveSvr retrieves pending messages from MsgStore and returns them to Phone B.

Sequence Mechanism for Loss‑Prevention :

Each user is allocated a 32‑bit sequence space (1 ~ UINT_MAX) that increments monotonically.

Every message is assigned a unique sequence number.

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

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

When the client’s sequence (Seq_cli) is lower than the server’s maximum (Seq_svr), the client can request the missing range (e.g., Seq_cli = 100, Seq_svr = 150 → fetch [101‑150]). After fetching, the client updates its Seq_cli to the latest value.

This mechanism also handles weak network conditions: if a server response is lost, the client will timeout, retry, and still be able to fetch the missing range because the server retains the sequence state.

Furthermore, when a user logs in from multiple devices, the server’s stored sequence ensures that already‑delivered messages are not resent, while undelivered messages are still delivered to the new device.

Summary : The described architecture satisfies the two core requirements of instant messaging—real‑time delivery (≈100 ms) and no message loss—by combining a storage‑forward model, push notifications, and a robust sequence‑based acknowledgment system. Although the architecture has evolved since 2014, the principles illustrated here remain valuable for designing large‑scale, reliable messaging services.