Designing Efficient Read/Unread Tracking for One-on-One and Group Chats

Common office communication tools such as DingTalk, Feishu, and WeChat Work provide read/unread indicators, which are essentially a binary state per message. In high‑traffic, large‑user scenarios, the challenge is to achieve this functionality while keeping performance and cost acceptable.

1. Design for One‑on‑One Chats

In a private conversation between user A and user B, each message has a unique, monotonically increasing ID. Instead of storing a read flag for every message, the system maintains a single "last read message ID" per conversation. For example, if user A’s last seen message ID with Zhang San is 91, all messages with IDs ≤ 91 are considered read, and IDs > 91 are unread. When the user scrolls to the newest messages, the read watermark is updated to the latest ID. This approach reduces storage to one record per conversation and makes updates trivial, resulting in excellent performance.

2. Design for Group Chats

Group chats can involve dozens to hundreds of participants, and an active group may generate hundreds of messages per minute. Several design options are discussed:

2.1 Database Table Scheme

Each message is recorded in a table with columns for message_id, user_id, and status (0 = unread, 1 = read). When a message is sent, a batch insert creates a row for every group member; when a user reads the message, an UPDATE changes the status. The logic is straightforward, but the volume of inserts and updates becomes prohibitive for large, active groups.

2.2 Redis Hash Scheme

Using a Redis HASH, the message ID serves as the key, the user ID as the field, and the value (0/1) indicates read status. Implementation is simple, yet a group of 10,000 users would require 10,000 field‑value pairs per message. With thousands of messages per day, the memory consumption quickly exceeds practical limits.

2.3 Watermark + Bitmap Implementation

Because group messages are ordered with strictly increasing IDs, each user can store a "read watermark"—the highest message ID they have read. To track which users have read a particular message, a bitmap is used: each bit represents a user (0 = unread, 1 = read). For a 10,000‑member group, a single message occupies less than 1.3 KB, so even tens of thousands of messages consume only dozens of megabytes. Updating a user's read status is a single SETBIT (or SEBIT) operation.

If user IDs are not sequential (as in distributed systems), the solution maps global user IDs to a group‑local sequential index via a member‑association table, then uses that index as the bitmap position.

Summary

(1) For one‑on‑one chats, maintaining only the last read message ID per conversation satisfies the read/unread requirement with minimal storage and high performance.

(2) For group chats, the bitmap + watermark approach scales efficiently for large groups; the Redis hash or direct MySQL table methods are viable for smaller groups or low‑concurrency scenarios.