Design and Implementation of a Modern IM Message Synchronization and Storage Architecture Using the TableStore Timeline Model

Instant Messaging (IM) systems have evolved from simple client‑server designs to complex distributed architectures that must support massive daily active users, real‑time message sync, and cloud‑based message roaming.

The core of an IM system is its message subsystem, which handles both message synchronization (delivering messages quickly and reliably) and message storage (persisting messages for later retrieval across devices).

Traditional architectures performed sync first and stored later, relying on online push for active users and offline queues for disconnected users, but they could not support message roaming. Modern architectures store messages first in two separate stores—a Message Storage Store for full‑history roaming and a Message Sync Store for multi‑device sync—then push to online clients, falling back to pull‑based sync when needed.

To simplify the design, the article introduces a logical Timeline model: a sequential queue where each message has a monotonically increasing SeqId. New messages are appended at the tail, and any consumer can read from any SeqId range, enabling both sync and roaming operations.

Based on the Timeline model, two concrete storage models are described: the Message Storage Model, which keeps a dedicated Timeline per conversation for full‑history access, and the Message Sync Model, which can use either read‑diffusion (single write, many reads) or write‑diffusion (multiple writes, single read) strategies. Write‑diffusion is preferred for IM because it reduces read pressure despite increasing write volume.

The article then outlines database selection criteria—support for a queue‑like schema, high‑throughput writes and range reads, massive data capacity, and TTL support—and recommends Alibaba Cloud TableStore, a distributed NoSQL store with LSM engine, auto‑increment columns, and built‑in TTL.

Implementation details are provided, including example TableStore SDK usage, table schema design for the two tables (PushTable for sync and StoreTable for storage), and sample code (shown within ... tags) that creates timelines, pushes messages, and pulls history for a group chat.

In conclusion, the Timeline‑based architecture enables clear separation of sync and storage concerns, supports multi‑device synchronization and message roaming, and can be extended to other real‑time scenarios such as feeds, live‑chat bullet comments, and more.