200B/s
deliveries if everyone gets every comment
Assume 0.2% of 10M viewers post in the same second at a wicket, 20,000 comments. At 150 bytes each, that’s 30 TB a second.
How do 10M phones hear about new comments?
Bad: Poll every 2 seconds
5M requests a second, nearly all returning nothing.
Good: One SSE connection each
Pay the connection once, then ≈333k tiny heartbeats a second.
A 12-viewer stream, 750 gateways. Who should hear its comment?
Only the two with its viewers. Gateways register their streams in a shared store; the dispatcher sends there, and each gateway fans out in memory.
Nobody reads 20,000 comments a second. Ten is already a fast scroll.
The trick
A selector keeps the best ~10 each second, per language, and collapses duplicates into “4,210 people said OUT”.
10M/s
frames, one per viewer per second
Ten selected comments plus the reaction tally ride one ≈1.5 KB frame. Each gateway serialises it once and writes the same bytes to up to 100,000 sockets.
Persist, moderate, then publish
- Take the stream’s next sequence number
- Store the comment, for replay and audit
- Check it inline, with a 150 ms timeout
- Publish only what passes; abuse never fans out
Frames arrive 101, 103, 102, 103, 106. Now what?
The sequence number set at write time lets the phone reorder, drop the repeat and spot the gap. Reconnects resume with Last-Event-ID.
Remember
Hold one connection per viewer, route by two-level subscriptions, persist and moderate before you publish, and give a hot stream ten selected comments a second in one frame.