Instant Messaging System Architecture: Synchronization, Storage, and Modern Design

In the era of mobile internet, instant messaging (IM) products like DingTalk, WeChat, and QQ have become essential, with the core of an IM system being its message subsystem, which focuses on synchronization and storage.

Traditional architectures synchronize messages first and store them later, relying on offline caches and lacking server‑side persistence, which prevents message roaming and results in low reliability. Modern architectures store messages before synchronization, using separate storage and sync databases to ensure persistence, support roaming, and enable near‑real‑time indexing.

The IM message model typically adopts an inbox (receiver‑centric) and outbox (sender‑centric) approach. Synchronization can follow read‑diffusion (pull) or write‑diffusion (push) patterns; IM systems usually prefer write‑diffusion because it reduces write amplification in read‑heavy scenarios, balancing a typical 10:1 read‑write ratio to a more manageable 30:30.

The message flow diagram illustrates three stages: (1) the green arrow shows the user sending a message, which is split by msg_gateway and placed into a partitioned MQ; (2) the blue arrow depicts server‑side push via msg_transfer , updating a global sequence in Redis, persisting the message in MongoDB and asynchronously in MySQL, then pushing to the recipient; (3) the pink arrow represents the client pulling missing messages after reconnection by comparing local and server sequence IDs.

Message storage is divided into a synchronization library (hot data in SSD for low‑latency reads, short‑term lifecycle) and a storage library (cold data in HDD for long‑term retention). Together with Redis, MongoDB, and MySQL, this stack provides fast synchronization, scalable storage, and reliable backup.

The article concludes with a brief recap and invites further discussion on detailed implementation.