Live updates
A normal request only answers when the client asks. A chat or a live score needs news to reach the user soon after it happens.
Polling
The client asks "anything new?" every few seconds. It is simple, but most answers are empty, which wastes work. News also waits for the next ask: with a 10 second gap, a message can take up to 10 seconds to show. 10,000 users polling every 5 seconds make 2,000 requests a second.
Long polling
The client asks, and the server holds the request open until there is news or a timeout, like 30 seconds. Then the client asks again at once. News shows almost right away, and far fewer answers are empty.
Server-sent events
The client opens one HTTP request, and the server keeps the response open. The server pushes small events down it whenever it likes. Data flows one way, server to client. To send something back, the client makes a normal request. If the stream drops, the browser reconnects by itself. Good for feeds, live scores and alerts.
WebSockets
A WebSocket starts as an HTTP request that asks to upgrade. After that, it is one long connection where both sides can send at any time. Good for chat, games and shared editing, where users send as much as they receive.
Many open connections
Every open connection uses some memory on a server, even when quiet. So apps use connection servers whose job is to hold many connections. With 1,000,000 users and 50,000 connections per server, you need at least 20. If Alice is on server 1 and Bob is on server 2, server 1 can't reach Bob. It publishes the message to a pub/sub system, and server 2, which subscribes for Bob, sends it to him. If a server dies, its clients reconnect to another one.
Remember
- Polling is simple but wasteful; long polling answers as soon as news comes.
- Server-sent events: server to client only.
- WebSockets: both ways, one long connection.
- Pub/sub passes messages between connection servers.