Long Polling vs WebSockets vs SSE

Back in the first module, HTTP was described as request and response: the client asks, the server answers, and that is the end of it. The model breaks down the moment the server needs to tell the client something the instant it happens: a new chat message, a live score, a price change. The server has no way to start a conversation, so the question is how to fake it, or how to replace it with something better. There are four answers, and each suits a different job.

You are expecting a parcel, and there are four ways to find out when it arrives. You can walk to the front door every ten seconds and look. You can ask the doorman to tell you when it comes, and he stands beside you saying nothing until it arrives (or an hour passes), and then you ask again. You can have a doorbell that rings every time something is delivered, so you only listen. Or you can have an intercom, where either of you can speak at any moment.

• -Walking to the door repeatedly is short polling: the client asks again and again, on a timer.
• -The doorman who holds you until there is news is long polling.
• -The doorbell is server-sent events (SSE): the server pushes, and the client only listens.
• -The intercom is a WebSocket: a two-way line that stays open.

Short polling is the easiest to build and the worst at scale. Say 100,000 users each ask for updates every 5 seconds. That is 100,000 / 5 = 20,000 requests a second, arriving whether or not anything has changed. If a given user gets one real update an hour, they make 3,600 / 5 = 720 requests in that hour and 719 of them, about 99.9%, find nothing. You pay for every one of those on the server and on the network, and the user still waits up to 5 seconds to hear anything. Shortening the interval cuts the delay but multiplies the load.

Long polling keeps the request open. The client sends a request and the server holds it, not answering until there is new data or a timeout is reached. The moment the client gets a response it sends another request. It works over plain HTTP with no special infrastructure, and it gives near-instant updates, but it keeps a connection tied up for each waiting client and pays for a new request after every message.

Server-sent events (SSE) use one long-lived HTTP connection over which the server pushes a continuous stream of events. Browsers reconnect automatically and can say which event they saw last, so the stream resumes where it stopped. It is simple and works over ordinary HTTP, but it is strictly one-way: the client cannot send data back on the same connection.

WebSockets give a true two-way, persistent connection. The client starts with an ordinary HTTP request that asks to upgrade, and if the server agrees, the same connection switches to the WebSocket protocol, after which either side can send a message at any time with almost no overhead:

The card below describes the WebSocket server component as it appears in the lab:

• -Need one-off updates, simplicity over efficiency? Long polling.
• -Need server-to-client only, over plain HTTP (live scores, price tickers)? SSE.
• -Need true two-way, low-latency communication (chat, multiplayer, collaborative editing)? WebSockets.

The diagram shows what makes a WebSocket different: a single long-lived pipe in both directions, instead of a fresh request and response for every message.

Holding connections open changes how you run servers, and it is worth knowing before an interviewer asks.

• -Connection count becomes the limit. If one server can hold about 50,000 idle connections, a million concurrent users need about 20 servers just to keep them open.
• -Servers must be able to message each other. A user connected to server 1 cannot receive a message that server 2 receives, unless the servers share messages through a publish/subscribe layer. The next chapter shows how.
• -Connections die silently. Phones change networks and proxies close idle connections, so clients and servers send small periodic heartbeats and the client reconnects, with a growing delay between attempts so a restart does not trigger a stampede.
• -Deploys drop connections. Restarting a server disconnects everyone on it, so roll out gradually and expect reconnect storms.
• -The load balancer must support the upgrade and keep long connections alive.