How WeChat Achieves Real‑Time, Lossless Messaging: Architecture Deep Dive

Background

WeChat, launched in 2011, reached 1.34 billion monthly active users by 2023. Its messaging service evolved from an email‑style store‑forward model to satisfy two core instant‑messaging requirements: sub‑100 ms delivery latency and zero message loss.

Message‑Sending Flow

When phone A sends a message to phone B the pipeline consists of two stages.

1. Phone A → Server

Phone A calls the access layer ConnectSvr. ConnectSvr forwards the request to the logic layer SendSvr. SendSvr performs anti‑spam and blacklist checks, then persists the message in MsgStore.

2. Server → Phone B

SendSvr

notifies the push layer PushSvr that a new message for phone B is ready. PushSvr looks up the long‑connection ConnectSvr that holds phone B and sends a notification.

If the long‑connection is unavailable (e.g., iOS releases resources after 10 minutes in background), PushSvr also forwards a push tip to the platform’s third‑party service (APNs, WPPush, BBPush, …). ConnectSvr delivers the notification over the existing long‑connection.

The third‑party push server forwards the tip to phone B.

Under normal conditions the end‑to‑end latency is ≈ 100 ms.

Message‑Receiving Flow

Phone B pulls the message after receiving the notification:

Phone B sends a pull request to ConnectSvr. ConnectSvr forwards the request to the logic layer ReceiveSvr. ReceiveSvr reads pending messages from MsgStore and returns them to phone B.

Loss‑less Delivery via Sequence Numbers

Each user owns a 32‑bit sequence space (1 … UINT_MAX). Four counters are tracked:

Server‑side maximum allocated sequence.

Server‑side maximum sequence already stored.

Client‑side maximum sequence received.

Client‑side maximum sequence acknowledged.

The server computes the delta between its Seq_svr and the client’s Seq_cli and delivers only the missing range.

Example 1 – Simple Increment

If Seq_cli =100 and Seq_svr =150, the client pulls messages 101‑150 and then updates Seq_cli to 150.

Example 2 – Subsequent Pull

Later Seq_cli =150, Seq_svr =200 → client receives 151‑200.

Example 3 – Device Switch

When the user logs in on a new device with Seq_cli =120 while the server knows sequences ≤ 150 have been delivered, the server skips 121‑150 and sends only 151‑200, avoiding duplicates. If the previous device never acknowledged 151‑200, the server still sends those messages to the new device to guarantee no loss.

Design Trade‑offs

Per‑message ACK would double round‑trip traffic and is vulnerable to ACK loss on weak networks.

The sequence‑based approach reduces traffic, tolerates lost server replies, and supports multi‑device login without duplicate delivery.

Server must persist the highest allocated sequence per user; client stores only the highest confirmed sequence, keeping state lightweight.

Key Takeaways

The architecture combines multi‑stage server processing, platform push services, and a robust sequence‑based acknowledgment protocol to meet sub‑100 ms real‑time delivery and zero‑loss guarantees. These principles remain applicable to modern high‑throughput messaging systems.