Realtime: WebSocket vs SSE vs polling
Three ways to do live updates on the web. Each has its niche. Most teams pick the wrong one for the job.
"Make this realtime" is a common ask. Chat, stock prices, notifications. Three tools, often the wrong one is picked.
WebSocket. Bidirectional channel. Client and server can both send messages. Use when:
- Chat or messenger.
- Multiplayer game or collaborative whiteboard.
- Real-time editing (Google Docs style).
Server-Sent Events (SSE). One-way stream from server to client. Plain HTTP. Use when:
- Stock prices, sport scores.
- Order status updates.
- Build progress, log streaming.
- Anything where server pushes updates and client doesn't reply.
Long polling / short polling. Client periodically asks "what's new". Hack, but useful when:
- Corporate networks block WebSocket.
- Updates are rare (every minute or longer).
- Backend can't hold long connections (some serverless platforms).
The common mistake: picking WebSocket for order status updates. Then fighting with reconnect logic, heartbeats, state recovery. SSE would have done the same job with 10% of the code and better reliability.
Default to SSE for server-to-client. Move to WebSocket only when you genuinely need bidirectional.