Decentralized Design and Architecture of QTalk Instant Messaging System

1. What is QTalk

QTalk started in 2015 as an automation office tool for Qunar, initially built by a four‑person team to replace RTX, which lacked a mobile version. Over three years the team grew modestly, adding business‑customer service scenarios and a custom call‑transfer system, and after 2017 shifted focus toward open‑source, decentralization, and intelligent bots.

The need for a proprietary IM arises because mainstream tools like WeChat are social‑oriented and do not meet enterprise requirements for security, privacy, and integration with custom applications, especially when handling sensitive data such as client lists or identity documents.

Office: secure transmission of core client information.

Travel: approval workflows on mobile without a computer.

Social: avoiding the need to add friends before communicating.

2. Past Design of QTalk

The early architecture relied on ejabberd for user‑hash based scaling, with three client connection types (TCP for duplex communication, UDP for audio/video, HTTPS for stateless operations). The system handled up to 30‑40 万 concurrent users without heavy tuning, but performance and capacity issues eventually emerged.

Statistics from a typical day: average online 6 500 users, 250 000 one‑to‑one messages, 100 000 group messages, with about 6000 individual users and 3000 group members, averaging 40 and 33 messages per user respectively.

These figures showed that the IM did not need to support billion‑scale users, but the architecture still required improvements.

3. Decentralization of QTalk

Decentralization was pursued to improve security, usability, and deployability rather than solely performance. The new architecture separates stateful services into a “Domain” layer that can be horizontally scaled and isolated, while stateless services reside in a “Public” layer.

Deployment now involves each organization running its own IM node; clients can connect to multiple nodes simultaneously. A Proxy component enables inter‑domain communication when cross‑department or cross‑company collaboration is needed, preserving data isolation while allowing controlled data exchange.

This design mitigates the risk of exposing business‑critical information to third‑party service providers, as all data remains within the organization’s own infrastructure.

4. Effective Cases

Commercial version QChat, used in Qunar’s website and app for pre‑sale and customer service, demonstrates the decentralized design in production.

A university campus management system employs independent deployments per college, integrates campus apps into the IM, and uses the IM as a unified authentication gateway.

Future articles will explore customer service features and AI bots.