Pushing Real-Time Updates

When you open Slack and see a message appear the instant someone sends it, or watch a chess piece move in real time during an Online Chess match, or see a Leaderboard update live during a competition — those aren't magic. Behind the scenes, the server is pushing data to your browser the moment something changes, instead of waiting for you to ask for it.

The fundamental question is simple: how does the server tell the client that something new happened? The answer shapes the architecture of every real-time feature you'll ever build. Get it wrong and you'll waste bandwidth polling for changes that haven't happened. Get it right and updates arrive instantly with minimal overhead.

Why Polling Falls Short#

The naive approach is polling — the client asks the server "anything new?" every few seconds. It works, but it's wasteful. Most responses come back empty ("no, nothing changed"), and there's always a delay between when data changes and when the client finds out (up to the full poll interval).

Long polling is a step up: the client sends a request, and the server holds it open until there's new data (or a timeout). This eliminates empty responses but still has overhead — each response requires a new HTTP request, and the server must hold connections open.

For low-frequency updates where simplicity matters more than latency — say, checking for new CI/CD pipeline results every 30 seconds — polling or long polling is perfectly fine. But for anything interactive, you need a persistent connection.

Protocol Choices: WebSockets vs SSE#

There are two main protocols for server-initiated push, and picking the right one depends on whether communication needs to flow in both directions.

WebSockets — Bidirectional Communication#

WebSockets upgrade an HTTP connection into a persistent, bidirectional TCP channel. Both client and server can send messages at any time without the overhead of HTTP headers on each message.

The connection starts as a normal HTTP request with an Upgrade: websocket header. The server responds with 101 Switching Protocols, and from that point on, the connection is a raw TCP pipe. Messages are tiny — just a few bytes of framing overhead compared to hundreds of bytes for HTTP headers.

Use WebSockets when the client needs to send data back frequently: chat messages in Slack, game moves in Online Chess, collaborative cursor positions in a Remote DevBox, or real-time prompts in ChatGPT.