Optimizing IM Architecture: Layered Design, Message Flow, and Quality Control

1. Background

Today we discuss IM architecture optimization. Building a complete IM system incurs high development and maintenance costs. Like many companies that only need instant messaging for certain business functions, we chose a third‑party IM service to reduce cost.

Providers such as Huanxin and Rongcloud offer mature enterprise solutions; we adopted Huanxin.

Third‑party services usually expose standardized interfaces; custom development incurs extra fees. By using only standard interfaces and building a thin customization layer, we lower cost and keep business data confidential, connecting only to message send/receive and long‑connection features.

2. Existing IM Logic

Early IM implementation only covered basic functions without an architectural concept. As business grew, the number and complexity of IM features increased, making a proper architecture essential.

Early code was tightly coupled. The new architecture can reference the existing coupling pattern.

3. Overall Architecture Design

A good architecture determines how far the code can go. The system is divided into four layers: Business, Architecture, Service, and Quality‑Control.

3.1 Architecture Layer

Service layer provides long‑connection services from the third‑party vendor.

Architecture layer encapsulates service interfaces and offers basic functionality to the business layer.

Quality‑control layer reflects system stability and business status.

Business layer focuses purely on business logic, isolated from service implementations.

3.2 Key Design Points

Separate third‑party services from business code to enable low‑cost replacement.

Encapsulate third‑party SDKs in a dedicated mobile architecture module; the module contains only interfaces, no business logic.

Backend platform architecture layer receives service callbacks, interacts with front‑end, and persists historical messages; it must be independent.

Front‑end mobile architecture layer packages core functions such as login, message distribution, conversation list, details, and persistence, allowing business developers to focus on pure business.

Quality‑control layer monitors stability, network, device, and external factors, providing alerts and evaluating third‑party service availability.

Testing environment includes a case library, essential test items, demo environment, and standardized test processes to reduce testing cost.

4. Offline, Online, and Historical Message Reception Optimization

Message reception is a challenge due to network conditions and user actions. Definitions:

Online message: Real‑time message received over a long‑connection.

Offline message: Message received when the user is offline; can be treated as part of historical messages on first login.

Historical message: Older messages that are usually read or discarded.

Key points:

Prioritize fetching newer messages first.

Offline messages should be fetched before switching to online state.

Implement reconnection mechanisms for offline retrieval.

Historical messages are generally not required for display unless business needs dictate.

Common offline retrieval strategies:

Pull offline messages after login together with online messages.

ACK‑Online mechanism: fetch offline messages first, then set user online and receive online messages.

Customizable offline/history pull with three modes: recent 7 days, 7‑30 days, and >30 days, allowing flexible data acquisition.

5. Unified Message Distribution Management

Message distribution uses a subscriber model to monitor send/receive status, login state, long‑connection health, and heartbeat. A dedicated distribution module centralizes IM logic from login to UI rendering, improving development efficiency.

6. Data Exception Handling Optimization

When pulling messages, failures may occur due to network issues. Implement retry mechanisms (at least three attempts), heartbeat checks, long‑connection monitoring, and status indicators to ensure data integrity and user awareness.

7. IM Metrics Design

Metrics are divided into three categories: third‑party service availability, data processing performance, and business‑related indicators. Specific IM metrics include response rate, conversation response frequency, and overall system health, which guide product design and code maintenance.