Building Real-Time Features: WebSockets, Polling, and What Each Costs
Key takeaway
Most "real-time" requirements are satisfied by polling every few seconds or by server-sent events. Reach for WebSockets when you need low-latency, bidirectional traffic — and budget for the connection state, scaling, and reconnection handling that comes with it.
"Make it real-time" usually means "the user shouldn't have to refresh". That's a much easier requirement, and picking the simplest mechanism that satisfies it will save you a great deal of operational pain.
The options, simplest first
- Polling — the client asks every few seconds. Trivial to build, works everywhere, cacheable. Wasteful at high frequency or large audiences.
- Long polling — the request is held open until there's news. Better latency, still plain HTTP, ties up a connection per client.
- Server-sent events — a one-way stream from server to client over HTTP, with automatic browser reconnection. Ideal for notifications, feeds, and progress updates.
- WebSockets — a persistent, bidirectional connection. The right answer for chat, collaborative editing, multiplayer, and live trading interfaces.
Ask these before choosing
- How stale can the data be? If five seconds is acceptable, polling is probably the answer.
- Does the client need to push as well as receive? If not, you don't need WebSockets.
- How many concurrent users? Persistent connections are a per-connection memory and file-descriptor cost.
- How often does data actually change? Polling an endpoint that rarely changes is cheap with proper caching.
What persistent connections cost you operationally
- Sticky routing or a shared pub/sub backplane, because a connection lives on one server instance.
- Deployment care — every deploy drops every connection, so clients need robust reconnection with backoff.
- Authentication on connect and re-authorisation on long-lived sessions.
- Backpressure handling for slow clients, or one bad consumer degrades the server.
- Proxies and corporate firewalls that terminate idle connections — heartbeats are mandatory.
A pragmatic default
Start with server-sent events for one-way updates and polling for everything low-frequency. Introduce WebSockets for the specific feature that genuinely needs bidirectional low latency, rather than converting the whole application. Managed services can absorb the connection-handling burden if real-time isn't your core differentiator.