Design and Architecture of a One‑to‑One Instant Messaging System

Instant messaging is an essential module for many software products, enabling real‑time communication between users or between users and customer service. This article walks through the design of a one‑to‑one IM system, covering functional breakdown, data storage, architecture layers, push‑pull strategies, and message processing.

1. Functional Decomposition

The basic features of an IM module include:

Conversation list ordered by the timestamp of the latest message.

Chat content page showing messages in chronological order.

Unread message count displayed next to the avatar.

User avatar and nickname information.

These features lead to the following data stores:

Conversation list.

Chat message records.

Offline message list.

Unread message counters.

User profile data.

2. Data Structures

Redis SortedSet is a convenient choice for ordered data. For the conversation list we can store:

key: prefix_xxx:{uid} value: {conversationId} score: {msgId}

For a single‑chat message list:

key: prefix_session_list:{sessionId} value: {msgId} score: {msgId}

Alternatively, a MySQL table can persist messages:

create table t_msg_record_list (
  `id` bigint not null primary key,
  `sessionId` bigint not null comment 'Conversation ID',
  `msgId` bigint not null comment 'Message ID',
  `isRead` tinyint not null default 0 comment 'Read status',
  `recordStatus` smallint not null default 0 comment 'Message status',
  `createTime` datetime not null,
  key `sessionId` (`sessionId`)
) engine=innodb;

Querying a page of messages:

SELECT msgId FROM t_msg_record_list WHERE sessionId = 1 AND recordStatus = 0 AND msgId > 1 ORDER BY id DESC LIMIT 10;

Offline messages can be indexed with a Redis Set and stored as a List:

key: prefix_xxx:{uid} → value: {senderUid}

key: prefix_offline_msg:{uid}:{senderUid} → value: {msgId}

Unread counters are derived from total messages minus read messages, stored per conversation and user:

key: prefix_session_count:{conversationId}:{uid} → value: total count

key: prefix_session_read_count:{conversationId}:{uid} → value: read count

3. System Architecture Layers

The architecture can be divided into five layers:

Client layer – multiple SDKs (web, app) hide underlying details.

Connection layer – long‑lived TCP/WebSocket connections maintain online status.

Business layer – separates long‑link (real‑time chat) and short‑link (profile queries) logic.

Service layer – micro‑services providing message filtering, storage, and async task handling.

Data layer – persistent storage using MySQL, Redis, or other databases.

4. Push‑Pull Mode Selection

Pure push wastes bandwidth when sending full history; pure pull suffers from latency and server load due to polling. A hybrid approach is recommended:

Push for real‑time delivery and notification when the user is online.

Pull for device initialization, historical chat pagination, and offline message retrieval.

5. Message Flow

Sending a message involves three steps:

Message filtering – SDK → logic layer → service layer for validation.

Message enrichment – add sender information.

Task dispatch – push the message to an asynchronous queue.

The async queue performs:

Persisting the chat record.

Updating total message count for unread calculation.

Determining online status to push immediately or store offline.

Updating the conversation list score.

Receiving a message includes appending to the chat list, marking as read via ACK, and updating read/unread counters and offline message state as needed.

Conclusion

The article has covered five aspects of a one‑to‑one IM system: functional decomposition, data structure design, system architecture, push‑pull mode choice, and message flow analysis, providing a solid foundation for implementing a production‑grade chat service.