Backend Development 15 min read

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.

58 Tech
58 Tech
58 Tech
Design and Optimization of MicroChat Backend Architecture for Multi-Device Message Synchronization

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.

backend architectureIMMessage Synchronizationoffline messagingread receiptsunread count
58 Tech
Written by

58 Tech

Official tech channel of 58, a platform for tech innovation, sharing, and communication.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.