How We Built a Scalable Mobile IM System for Travel Apps

Part 1: Design and Overall Architecture

We combined B2C, C2B, and C2C scenarios to implement private messaging, user inquiries, and feedback features in the travel app, and added merchant‑side conversation management, customer‑service tools, and operational statistics.

The IM business includes data‑channel and abnormal reconnection mechanisms, real‑time message subscription and distribution, and a generic UI solution for conversation lists.

Part 2: Technical Principles and Implementation

2.1 General Data Channel

For non‑real‑time data the client makes one‑way HTTP requests, but IM messages require a stable, bidirectional channel. We use an HTTP long‑polling connection that carries a unified data‑packet structure, allowing multiple business types to share the same channel and reducing creation and maintenance costs.

2.2 Message Subscription and Distribution

The system follows a publish‑subscribe model: publishers classify messages, subscribers receive them. Subscriptions decouple business logic from channel handling, allowing interceptors for parsing, filtering, error handling, and data collection.

2.3 Conversation List UI Rendering

Different scenarios (private chat, service inquiries, feedback) share a common conversation‑list structure. We map message types to specific UI layouts, using a generic container for shared elements (avatar, name, timestamp, read status) and type‑specific sub‑views for content.

Part 3: Detail Optimizations & Pitfalls

Message deduplication: we introduced a random_id (random number + timestamp) to identify a message uniquely across retries, allowing the server to filter duplicates.

Local push: instead of relying solely on remote push services, we combine the data channel with local notifications, attaching push‑display data to messages and suppressing duplicate alerts on the active page.

Reconnection mechanism: the original polling retry sent five rapid requests after an error, which could overload the server. The improved version randomizes delay between 5‑20 seconds and spreads retries, also adding delayed retries when the client is offline.

Message line (conversation identifier): we replaced the previous business‑source‑based lookup with a dedicated message_line_id stored in a DB table (uid + object_id + busi_type). This reduces DB queries, removes frequent interface calls, and simplifies client logic.

Part 4: Outlook and Recent Optimizations

4.1 Upgrade to WebSocket

WebSocket provides full‑duplex communication over a single TCP connection, reducing protocol overhead, improving real‑time delivery, maintaining connection state, supporting binary frames, and allowing extensions such as compression.

Lower control overhead (2‑10 bytes header vs full HTTP headers).

Stronger real‑time capability (server can push anytime).

Stateful connection reduces repeated authentication data.

Better binary support and extensibility.

Higher compression efficiency with context sharing.

We plan to replace the HTTP long‑polling implementation with WebSocket to boost channel efficiency.

4.2 Business Function Expansion

Future work includes turning the IM module into a reusable component for other products, adding support for short videos, voice messages, quick replies, group chats, interest channels, and multi‑person audio/video communication.

These enhancements aim to improve user experience and continue empowering merchants.