How TableStore Powers Scalable IM Message Sync and Storage

Architecture Overview

Instant Messaging (IM) has become essential in the mobile internet era, with products like DingTalk, WeChat, and QQ built around IM core functions. Modern IM systems have evolved from simple CS/P2P architectures to complex distributed systems handling massive daily active users.

Message System Core

The heart of an IM system is the message subsystem, which focuses on message synchronization and storage. Synchronization ensures messages are delivered quickly and completely, supporting online/offline push and multi‑device sync. Storage refers to cloud persistence, enabling message roaming across devices.

Traditional vs. Modern Architecture

Traditional architecture synchronizes messages first and stores them only for offline users, lacking message roaming. Modern architecture stores messages first, using two databases: a Message Storage DB for full conversation history (supporting roaming) and a Message Sync DB for multi‑device synchronization, allowing both online push and pull mechanisms.

Timeline Model

The Timeline model abstracts message queues with three key properties: each message has an increasing SeqId, new messages are appended at the tail, and messages can be randomly accessed by SeqId or range. This model simplifies both synchronization and storage, enabling multi‑device sync and roaming.

Message Sync Models

Read‑expansion : Messages are written once to a conversation Timeline; receivers pull updates, reducing write load but increasing read traffic.

Write‑expansion : Each receiver has a dedicated sync Timeline; messages are written multiple times (once to storage and once per receiver), simplifying reads at the cost of higher write volume. IM systems typically use write‑expansion to balance read/write ratios.

Message Database Design

Two databases are required: the Message Sync DB (short‑lived messages for sync, often with TTL) and the Message Storage DB (long‑term storage for roaming). They have different requirements for durability and lifecycle management.

Database Selection

Alibaba Cloud TableStore, a distributed NoSQL database with LSM storage, supports millions of TPS, petabyte‑scale data, TTL, and auto‑increment columns, making it ideal for implementing the Timeline model.

Implementation Highlights

Sample code (not shown) demonstrates creating two TableStore tables— PushTable for sync and StoreTable for storage—followed by logic for pushing messages to group members and pulling history using SeqId ranges.

Conclusion

The Timeline‑based architecture, combined with TableStore’s features, provides a clear, scalable solution for IM message push and storage, applicable to feeds, live comments, and other real‑time synchronization scenarios.