How We Built a Scalable Mobile IM System for a Travel App

Design Idea and Overall Architecture

Mobile internet has reduced distribution cost, enabling direct communication between users and service providers. To support B2C, C2B, and C2C scenarios, we built private messaging, user consultation, and feedback features in the travel app, and added merchant‑side conversation management.

IM business includes a data channel with reconnection, real‑time subscription and distribution, and a generic UI for conversation lists.

Technical Principles and Implementation Process

2.1 General Data Channel

For non‑real‑time data a one‑way request is enough, but IM requires a stable bidirectional channel. We encapsulate all messages in a uniform packet and use an HTTP long‑polling channel to deliver them.

2.1.1 Basic Interaction Principle

All communication data are wrapped in a common outer structure so multiple business types share the same channel, reducing the number of connections and maintenance cost.

2.1.2 Client Data Channel Implementation

The client maintains a request stack for different business scenarios; each long‑polling request uses the top of the stack, allowing business layers to register handlers and receive messages.

2.2 Message Subscription and Distribution

Publish‑subscribe decouples producers and consumers. Subscribers register for specific message types, enabling unified management, filtering, error handling and data collection.

2.3 Conversation List UI Rendering

We analyze commonalities among private chat, service consultation, etc., and map message type, data structure and layout via a management table, allowing fast iteration and reuse.

Detail Optimizations & Lessons Learned

3.1 Message De‑duplication

We introduced a random_id (random + timestamp) to uniquely identify a message across retries, preventing duplicate delivery.

3.2 Local Push

Instead of relying solely on remote push, we combine the data channel with local notifications, sending push data only when the app is in the background, which improves delivery reliability and reduces server pressure.

3.3 Data Channel Reconnection Mechanism

We refined the retry strategy: for up to five consecutive errors, use a random 5‑20 s delay; after network loss, delay retries to avoid overwhelming the server.

3.4 Unique Conversation Identifier

We added a conversation line ID (uid + object_id + busi_type) stored in a DB table, replacing earlier parameter‑based identification and simplifying merchant assignment and push decisions.

Future Outlook & Recent Optimizations

4.1 Upgrade Data Channel to WebSocket

WebSocket provides full‑duplex communication, lower protocol overhead, better real‑time performance, stateful connections, binary support, extensibility, and improved compression compared with HTTP polling.

4.2 Business Function Expansion

We plan to turn the IM module into a reusable component, adding support for short video, voice messages, quick replies, group chats, interest channels, and multi‑person audio/video, thereby reducing development cost and enriching user interaction.

These improvements aim to enhance user experience and continuously empower merchants.