Designing Scalable Group Chat Read Receipts: Push vs Pull and Optimization Strategies

1. Group Message Delivery Process and Guarantees

The discussion starts by outlining the core questions for group messaging: whether messages are stored once or per member, and how to track which members have read each message.

Answer 1: Store a single copy of each group message to avoid massive redundancy.

Answer 2: Record each member’s last_ack_msgid (or last_ack_time) to indicate that all messages before this ID are read, while later messages remain unread. This requires only one value per user.

The essential data structures are: group_msgs(msgid, gid, sender_uid, time, content) – records each group message. group_users(gid, uid, last_ack_msgid) – records group members and the last message each has acknowledged.

The sending flow proceeds as follows:

A user sends a group message.

The server persists the message and queries the group’s member list.

Online status of each member is checked.

Online members receive a push notification.

Once the message is persisted, loss is prevented.

2. Read Receipt Process

To know how many members have read a message, a receipt table is introduced: msg_acks(sender_uid, msgid, recv_uid, gid, if_ack) Fields represent the sender, message ID, receiver, group ID, and acknowledgment flag.

After adding read‑receipt logic, the flow changes slightly:

Server stores the initial receipt state for each message.

When a client acknowledges, it updates last_ack_msgid and sets if_ack to true.

The client then queries the sender’s online status.

If the sender is online, the acknowledgment is pushed immediately; otherwise it is fetched on the sender’s next login.

For offline members, the client pulls unread messages on the next login and updates last_ack_msgid to the latest message.

If an acknowledgment is lost, duplicate messages can be filtered on the client side using msgid.

3. Optimization Proposals

Given a group of 200 users with 20% online, each message generates roughly 40 push notifications, 40 acknowledgment updates, and 40 read‑receipt pushes—a large “message storm.” To mitigate this:

Batch acknowledgments: after receiving N messages (e.g., 10), send a single last_ack_msgid update covering all prior messages, reducing request volume by a factor of N.

Allow the sender to poll for read receipts (e.g., every minute) instead of receiving real‑time pushes, dramatically lowering traffic.

Physically delete read‑receipt records after they are no longer needed, or archive them after a configurable retention period, to control storage growth.

Potential side effects include delayed receipt visibility (up to the polling interval) and possible duplicate message retrieval after abnormal client termination, but these can be handled by client‑side de‑duplication without harming user experience.

4. Summary

In typical group chat scenarios:

If the sender is online, read receipts are pushed in real time.

If the sender is offline, receipts are fetched on the next login.

Optimization strategies include batching acknowledgments, polling for receipts, and cleaning up receipt data to reduce storage and network load.