One event at 7 s, delivered four ways
Short polling finds it on the next poll. Long polling answers a parked request. SSE and WebSockets write it into a connection already open.
92%
of polls come back empty
A million clients polling every 5 s make 200,000 requests a second. If an order changes once a minute, 11 of every 12 find nothing new.
SSE is one never-ending response carrying events, each with an id:. Then the connection drops.
Built in
The browser reconnects by itself, sending Last-Event-ID. Replay from that ID: no gap, no client code.
A WebSocket starts as HTTP, then stops being HTTP
One GET with Upgrade: websocket, a 101 reply, and the TCP connection carries frames both ways. A 50-byte message costs 56 bytes.
SSE or WebSockets?
Bad: “Because it’s real time”
You then build reconnect, heartbeats and resume, and some proxies block it.
Good: Name the reason
One-way updates? SSE, resume built in, writes as POSTs. Both ways, often? WebSockets.
Which gateway holds Ravi’s socket?
Sockets pin state to one machine for hours. A registry maps user → gateway; pub/sub carries the message there. Store it first: Redis pub/sub can drop it.
5.5×
as many handshakes when clients retry in lockstep
Assume a gateway with 100,000 sockets dies and the rest accept 10,000 a second. Retry every second: 450k rejected. Wait a random 0–20 s first: none.
Remember
SSE for one-way feeds, WebSockets when the client talks often. Thin gateways hold the sockets; a registry and pub/sub route messages. Persist first, and reconnect with jitter from the last sequence number.