Ensuring Reliable Message Delivery in QTalk Instant Messaging System

1. Introduction

Instant Messaging (IM) is a real‑time communication service that supports private chatrooms, group conversations, multimedia messages, priority handling, and message traceability. This article explains how Qunar's own IM system, QTalk, ensures stable message delivery and discusses its current bottlenecks.

2. What is QTalk

QTalk is an internal communication tool launched by Qunar in 2015, developed and maintained by its own team to replace Tencent's RTX, which suffered frequent company‑wide issues and lacked a mobile version. Over time, QTalk and its derivatives (e.g., QChat) have become the primary IM service for Qunar employees and business units.

3. Why IM Messages Can Be Lost

Because IM relies on a persistent long‑connection for duplex communication, it is vulnerable to several conditions:

Complex network environments or frequent VPN switches.

Mobile network switches, weak signal areas, or overloaded base stations.

Abnormal packets that force the connection to close.

PC sleep mode causing network card power loss.

These scenarios trigger reconnections; messages generated during reconnection may be missed, leading to loss.

4. Mechanisms to Ensure Stable Delivery

QTalk addresses three aspects: sending, transport, and reception.

Sending side strives to guarantee successful transmission.

Potential multiple sends are de‑duplicated to ensure message uniqueness.

Backend shortens routing paths to minimize loss.

Backend uses queues to guarantee inter‑node delivery.

Receiver maintains a stable connection or proactively fetches history after disconnection.

Message Sending Mechanism

Key points:

Only when the server acknowledges receipt is a message considered successfully sent.

If no acknowledgment arrives within a timeout, the message is marked as failed.

Failed messages either enter a limited retry loop or are shown as failed for user‑initiated resend.

Message Receiving Mechanism

Reception relies on network health checks triggered by periodic heartbeats or any request timeout.

Heartbeat detection.

Any request timeout initiates a connection check.

When a real disconnection is detected, the client quickly reconnects, obtains a token, and syncs any missed messages from the server.

5. Advanced: Multi‑Client Synchronization

To keep messages consistent across multiple logged‑in devices (e.g., PC and mobile), QTalk ensures:

Each client maintains its own long‑connection.

The server decides whether to deliver a message to a specific connection or all of a user's connections (QTalk uses the latter).

When a message is sent from one client, the server pushes a special copy‑forward message to other logged‑in clients, which interpret it as a new message.

If a connection drops, the same compensation logic applies.

These steps complete the overview of QTalk's reliable delivery mechanisms.

6. Future Improvements

Multi‑Level Delivery Receipts

Currently only the sender receives an acknowledgment; there is no receipt confirming that the message reached the recipient. Implementing this is a lower priority because the single‑node backend already achieves near‑100% delivery, but it may become necessary for larger platforms like QChat.

Handling Exceptional Network Conditions

While most network scenarios are covered, edge cases such as overseas networks are less robust and may require additional handling.

Balancing Reconnection Frequency

Only a few core requests currently trigger reconnection on failure; expanding this to more requests must balance overall efficiency and user experience.