Group Chat Design: Write Fan-out or Read Fan-out?

Preface

In IM systems, group chat is a core and high-frequency scenario. Around the topic of "store multiple copies" vs. "store a single copy" for group messages, there has been a great deal of debate online. Today, we'll discuss the pros and cons of both approaches.

"Store Multiple Copies" — the Write Fan-out Model

Sending a message in a group can be directly analogized to delivering the message to each group member separately. This way, the handling of group messages becomes similar to that of single chat — namely, a 1-to-N version of single chat — and can maximally reuse the single-chat handling model. As shown in the figure below, each user independently maintains a message queue, called an inbox, where every received message is kept in time order. This is a typical write fan-out model.

Advantages:

1. Good message-receive performance, especially for users joined to multiple active large groups. Since messages are pre-organized per user, they can be received efficiently using incremental sync.
2. Per-user message ordering is relatively easy to control, making it convenient to maintain consistency across multiple devices.
3. Messages between users are independent and don't affect each other. A user's operations on a single message (e.g. delete, mark) do not affect other recipients of that message.
4. The client logic is relatively simple. All new messages from joined groups are pushed or pulled to the client in time order, and only need to be handled in a unified message listener.

Disadvantages:

1. Higher message storage cost. Because messages are organized per user, group messages are stored multiple times according to the number of members.
2. Higher storage write QPS. For the same reason, the more group members, the higher the message write QPS.
3. Operations like message recall and edit are complex to handle, since each member's copy of the message must be processed separately, consuming more compute and storage.

"Store One Copy" — the Read Fan-out Model

Group messages are stored only once per group, with all group members sharing this single message store. This is the read fan-out model.

Advantages:

1. Low storage cost. Messages only need to be stored once per group.
2. Operations like message recall and edit are easy to handle, since they only need to be processed once.

Disadvantages:

1. Poor message-receive performance. You must first search, per user, which groups have new messages, and then query each group's new messages one by one.
2. One-sided message deletion is hard to handle. One-sided deletion is a per-user operation — everyone has different needs. With only one copy of group messages, you have to mark deletions per user.

A Hybrid Approach

Both read fan-out and write fan-out have their pros and cons, and each fits different scenarios. Real-world scenarios are often more complex — it's hard to be purely one or the other. So is there a hybrid model that takes the strengths of both while avoiding their weaknesses?

Of course! JuggleIM's group message model takes advantage of both read fan-out and write fan-out, in order to strike a good balance between performance and cost.

Specific approach:

1. Use write fan-out to generate the conversation list. Each user gets a separate conversation list that only stores the last message of that conversation. This greatly reduces the storage cost introduced by write fan-out. In addition, each conversation tracks its unread count and read marker, so users can quickly find which conversations have new messages.
2. Use read fan-out to store group messages. Group messages are stored only once per group, with conversations as the index driving the retrieval of unread messages, improving receive performance. Each group message also maintains a continuously increasing sequence number. With this, the client can quickly detect local message gaps, and use the server's history message API to backfill messages on demand.
3. Further optimizations:
4. For online users, prioritize write fan-out to improve their message experience; for offline users, prioritize read fan-out to balance performance and cost.
5. For offline group members (which is the majority in most cases), a lot of merging and batch processing is applied, significantly improving the efficiency of handling this data.
6. No upper limit on group size. In fact, JuggleIM on a single node can support dozens of groups with over 100,000 members concurrently.

JuggleIM Experience

Official site: https://www.juggle.im
Open-source repository: https://github.com/juggleim
Demo experience:
Web: https://im.juggle.im
iOS: https://testflight.apple.com/join/XucKbQ54
Android: Coming soon

---