How WeChat Guarantees No Lost Messages: The Secrets of Reliable IM Delivery

This article explains the three types of IM packets—Request, Acknowledge, and Notify—illustrates the basic message flow between client and server, identifies reliability gaps such as lost notifications, and proposes an application‑level solution using acknowledgments, timeout‑driven retransmission, and message deduplication to achieve dependable delivery.

ITPUB
ITPUB
ITPUB
How WeChat Guarantees No Lost Messages: The Secrets of Reliable IM Delivery

Message Types in IM Systems

IM protocols typically define three packet categories:

Request (R) : client‑initiated message sent to the server.

Acknowledge (A) : server’s response confirming receipt of a Request; each A corresponds to one R.

Notify (N) : server‑initiated notification delivered to the client.

Message type diagram
Message type diagram

Basic Message Delivery Process

A simple flow for sending a text like “hello” works as follows:

client‑A sends msg:R to the IM server.

The server replies to client‑A with msg:A to acknowledge receipt.

If client‑B is online, the server forwards msg:N to client‑B.

If client‑B is offline, the server stores the message for later delivery.

Basic delivery diagram
Basic delivery diagram

Problems with the Simple Flow

When client‑A receives msg:A, it only knows that the server has accepted the message; it cannot confirm that client‑B actually received it. In real‑world scenarios, the msg:N packet may be lost due to server crashes, network jitter, or client‑B crashes, leaving client‑A unaware of the final delivery status.

Application‑Level Reliability Mechanism

To guarantee delivery, an explicit acknowledgment cycle is added:

client‑B sends ack:R to the server after processing the original message.

The server replies with ack:A to client‑B.

The server then sends ack:N back to client‑A, confirming that client‑B has successfully received the message.

Acknowledgment flow diagram
Acknowledgment flow diagram

Handling Lost Packets and Retransmission

If client‑A does not receive ack:N within a predefined timeout, it retransmits the original msg:R. To manage multiple in‑flight messages, client‑A maintains a "waiting‑ack queue" and a timer for each entry. When the timer expires without receiving the corresponding ack:N, the message is resent with the same msgid.

Waiting ack queue diagram
Waiting ack queue diagram

Deduplication at the Receiver

Client‑B must discard duplicate messages that may arrive because of retransmissions. It does so by generating a unique msgid for each logical message, storing this identifier in the waiting‑ack queue, and ignoring any subsequent msg:R with the same msgid.

Key Takeaways

The system ensures reliable delivery through timeout, retransmission, acknowledgment, and deduplication mechanisms.

A single "hello" transmission consists of six packets: three in the forward direction (msg:R/A/N) and three acknowledgments (ack:R/A/N).

The waiting‑ack queue is essential for tracking unacknowledged messages and coordinating retries.

Absolute loss‑free, duplicate‑free delivery can only be guaranteed at the application layer, not at the lower network or system layers.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Backend ArchitectureIMMessage ReliabilitydeduplicationAcknowledgmentretransmission
ITPUB
Written by

ITPUB

Official ITPUB account sharing technical insights, community news, and exciting events.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.