Designing Efficient Read/Unread Tracking for Group Chat Messages Using Bitmaps

Enterprise instant‑messaging platforms often show a read/unread count for each group message, requiring storage of a unique messageid and a unique userid per user; the article examines how to store this information efficiently.

A straightforward approach keeps two lists (readids and unreadids) for every message, but interviewers consider it unsatisfactory because it scales poorly.

For a 200‑member active group, the naïve method consumes 8 bytes per member per message (≈1.6 KB per 1 K daily messages), which is unacceptable for mobile clients and costly for servers.

The author suggests using a bitmap to represent the 0/1 read status, assigning each user a sequential mapid that maps to the real userid .

Data structures:

struct UserInfo {
    uint64_t userid;
    uint32_t mapid;
};

struct GroupMetaInfo {
    vector
members;
    string name;
    uint32_t maxid;
    // other info
};

Each message can then store:

{ uint32_t maxid, uint8_t readbit[] }

For example, a group of five members uses a 5‑byte record ({5, readbit[0]=0000 0000}); when member D reads the message the bitmap becomes 0000 1000, and when four members have read it becomes 0001 1110.

To handle members leaving the group, a second bitmap ( quitbit ) records whether a member has exited at the time of sending, and deletions are marked rather than physically removed, preserving the mapid mapping.

The final design stores per‑message data as {maxid, readbit[], quitbit[]} , adding negligible overhead while cutting the per‑member storage from 8 bytes to roughly 2 bits, achieving a >95 % reduction (e.g., 200 members require only about 54 bytes instead of 1.6 KB).

If maxid grows to millions, the scheme can fall back to the original method, but in typical enterprise scenarios group sizes are limited, keeping the bitmap approach practical.