Signals that it’s real-time updates
- “Live”, “as it happens”, “in real time”
- The server learns first
- Fresh within about a second
- Many recipients per event
WebSockets for everything?
Bad: WebSockets for scores and tokens
A stateful tier for data that only flows down.
Good: SSE for one-way updates
Plain HTTP; sends are POSTs; Last-Event-ID resumes.
Climb the ladder. WebSockets are only the middle.
The last mile picks a transport. The hard part starts at the second gateway, then losing nothing, then one huge room.
Store first, then publish once
The message service numbers and stores Asha’s message, then publishes it once to conv:42. Only gateways holding members receive it; offline Dev gets a mobile push.
Redis Pub/Sub drops a message in a blip. Lost?
The trick
No. It was already stored as sequence 119. Pub/sub is a doorbell, not a mailbox; the client spots the gap and fetches it.
Resume: subscribe, replay, drop duplicates
Back from a tunnel at 117, the client resumes. The gateway subscribes first, replays 118 to 120 from the store, then streams live. The client drops a repeated 120.
1,700
reconnects a second, jittered over 30 s
A gateway holding 50,000 sockets dies. Retrying at once, then every second, costs 275,000 attempts. Full jitter stays under budget from the first second.
A million viewers: change what you send
Sending all 2,000 comments a second to a million viewers is 2 billion sends. Sample, batch two frames a second, and relay: the publisher sends 8 messages a second.
Say it like this
Pick the simplest last mile, SSE if updates flow down and WebSockets if clients talk. Store with a sequence, publish once per conversation, resume after reconnects, and sample huge rooms.