Chat
Groups and history
Before you start
- Open lesson
Pick the key every read has
Messages are partitioned by conversation and ordered by a sequence number.
Why it matters
A message in group g7 must reach online members quickly and remain in history for all 500 members. Making the sender touch every inbox or socket turns one post into 500 synchronous actions, and one busy room can pin the app server that accepted it. The sender’s request must do constant durable work and must not open 500 member connections.
Example
Design a group chat
Up to 500 members share a conversation. A message reaches online members quickly and appears in history for everyone.
- Input
- group = {"log": [], "cursors": {}}
- Output
- ["lunch?"]
Approach 2 · Resolve the bottleneck
The idea
Keep one example in view
Design a group chat
group = {"log": [], "cursors": {}}→["lunch?"]
The baseline, Copy into every inbox, is 500 writes per message · members × messages. The better model below keeps this exact input and removes that bottleneck.
Instead of writing g7’s “lunch?” into 500 inboxes, append it once as seq 3, publish g7:3 to connection servers for online members, and use Cy’s cursor 2 to read the message later.
Append “lunch?” once to g7’s log as sequence 3, then publish g7:3 to a channel keyed by conversation id. Connection servers that currently hold g7 members’ sockets subscribe and push the live copy, distributing CPU beyond the sender’s server.
Store one read cursor per member. Cy’s cursor at 2 makes her next history range start at sequence 3, and unread count is log length minus that cursor. Five hundred cursors are modest; a 500,000-member broadcast needs a different model with less per-member state.
Visual anchor
Design a group chat
group g7: one log for all 500 members
Pro
The rest of this is on Pro
The idea above is free. The walkthrough, the cost, and the practice are on Pro.