How We Built a Scalable Mobile IM System for Travel Apps

Part 1: Design Idea and Overall Architecture

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

Current IM business includes private chat, user consultation, and feedback.

IM data channel with exception reconnection to ensure real‑time delivery and stability.

IM real‑time message subscription and distribution to avoid unnecessary requests.

General UI solution for conversation list to simplify development across message types.

Part 2: Technical Principles and Implementation

2.1 General Data Channel

For regular data display the client makes one‑way requests, but IM requires bidirectional, low‑latency communication, so a stable, long‑lived data channel is created between client and server.

2.1.1 Basic Interaction Principle All communication data is wrapped in a uniform outer packet, allowing multiple business types to share the same channel and reducing channel creation overhead.

2.1.2 Client Data Channel Implementation The client maintains a request stack representing the current business scenario; each HTTP long‑poll request uses the top of the stack, enabling scenario‑specific handling while keeping the channel agnostic to payload content.

2.2 Message Subscription and Distribution

Subscription follows a publish‑subscribe model: publishers classify messages, subscribers receive only the types they care about, enabling unified management, interception, filtering, and data collection.

2.2.1 Subscription Business logic registers interest in specific message types; the framework automatically monitors page lifecycle and removes subscriptions on page destruction, reducing coupling.

2.2.2 Distribution The data channel maintains a subscriber list per message type and forwards parsed messages to the appropriate business handlers.

2.3 Conversation List Rendering

Different scenarios (private chat, service feedback, etc.) require varied list presentations, but share common UI elements. We map message type, data structure, and layout to enable reusable rendering.

2.3.1 Message List Structure Each message type is associated with a specific layout; incoming messages are matched to their layout and added to the list.

2.3.2 Type‑Layout Mapping A mapping table links message type, data structure, and UI layout, allowing fast lookup during rendering.

2.3.3 UI Rendering Process Rendering is split into a generic container creation step and a type‑specific styling step, handling common elements (avatar, name, timestamp, read status) uniformly while allowing extensible custom UI.

Part 3: Detail Optimizations & Lessons Learned

3.1 Message Deduplication Introduced a random_id (random number + timestamp) to uniquely identify a message; duplicate retry requests carry the same random_id, enabling server‑side deduplication.

3.2 Local Push Combined data channel notifications with local OS notifications to inform users of new messages when the app is in the background, reducing reliance on third‑party push services.

3.3 Data Channel Reconnection Improved the polling‑based reconnection strategy by randomizing retry intervals (5‑20 seconds) and limiting rapid retries, preventing server overload during network outages.

3.4 Unique Conversation Identifier Added a dedicated message‑line ID to replace business‑source lookups, reducing DB query cost, simplifying push logic, and lowering client complexity.

Part 4: Outlook and Near‑Term Optimizations

4.1 Upgrade to WebSocket Migrating the data channel from HTTP long‑polling to WebSocket reduces protocol overhead, improves real‑time performance, maintains connection state, supports binary frames, and enables compression extensions.

4.2 Expand IM Functionality Plan to refactor the mobile IM module into a reusable component that can be quickly integrated into other business lines, adding support for short video, voice messages, quick replies, group chats, and multi‑party audio/video communication.