Design and Optimization of MicroChat Backend Architecture for Multi-Device Message Synchronization
The article explains the MicroChat instant‑messaging backend architecture, detailing its long‑connection, access, logic, and storage layers, and describes how message synchronization, offline handling, hole‑filling, unread count roaming, and read receipts are implemented and optimized for multi‑device use.
Overall Architecture
MicroChat is the instant‑messaging tool of the 58 Group, supporting PC, mobile web, and app clients. Its backend consists of four main components: a long‑connection channel that pushes data from server to client, an access layer that receives short‑connection requests, a logic layer that handles heavy business logic and asynchronous tasks, and a storage service built on the self‑developed distributed KV store wtable for persisting messages.
Message Synchronization and Roaming
The classic IM message flow involves four steps: client A calls the access layer, the access layer stores the message via the logic layer, the server pushes the message through the long‑connection to client B, and client B acknowledges receipt. This synchronous chain is slow and fragile.
MicroChat splits the process into two phases: the client sends the message and the server stores it, immediately returning success; a separate asynchronous task later delivers the message to the recipient via the long‑connection, ensuring reliable delivery.
For offline recipients, the server tracks which messages have not been acked. It sends push notifications for undelivered messages and, when the client comes online, pushes the missing messages.
Hole Filling
When a client reinstalls the app, changes devices, or switches between multiple devices, previously acked messages may be missing locally. Each message stores the ID of its predecessor, forming a linked list. If a client detects a gap (a missing predecessor), it requests the missing segment from the server, completing the “hole”.
Message Synchronization Optimization
To avoid pulling the entire history when only recent messages are needed, MicroChat introduces the concepts of a conversation and a conversation list. Each conversation records the latest message ID and the previous message ID (the head of the linked list). When a client syncs, it uses these heads to fetch only the missing range.
During concurrent message arrivals, storing only the head prevents both messages from incorrectly pointing to the same predecessor, thus preserving correct order without excessive server updates.
The client‑side sync flow is:
On login, the client synchronizes the conversation list and updates conversation attributes.
It compares the stored latest and previous message IDs to detect gaps.
If gaps exist, it pulls missing messages in reverse chronological order, page by page.
Unread Count Roaming
Each conversation tracks an unread count. Early versions calculated this locally, which broke across multiple devices. MicroChat now stores msgIndex (a monotonically increasing sequence per conversation) and showedCount (the highest index the user has displayed). Unread count = msgIndex – showedCount .
When a user reads messages, the client reports the latest msgId and msgIndex to the server, which stores the reading progress. This allows both online and offline devices to obtain the latest unread count on next login.
Read Receipts
Read receipts indicate whether the recipient has viewed a sent message. MicroChat records the reading progress per conversation; the other side can compute which of its messages have been read based on the peer’s showedCount . The server updates the progress and pushes it to all online devices, while offline devices receive it on next sync.
User reads messages and reports the reading progress to the backend.
The backend updates the conversation’s progress.
If other devices of the same user are online, they are notified of the update.
If the peer is online, its devices are also notified.
The reporting client receives the latest read‑receipt status for its view.
Conclusion
MicroChat’s backend architecture ensures real‑time delivery, data completeness, and reliable multi‑device synchronization through asynchronous message pushing, hole‑filling linked lists, optimized history pull, unread‑count roaming, and read‑receipt mechanisms, continuously improving user experience for the 58 Group’s instant‑messaging platform.
58 Tech
Official tech channel of 58, a platform for tech innovation, sharing, and communication.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.