Real-time Communication: WebSocket vs SSE vs Long Polling
When a server must push data to a client immediately (chat, live score, location), plain request-response is not enough; you need a persistent connection.
28.1 Why is it used?
- In HTTP the server only speaks when the client asks; polling a live score every second means lakhs of useless requests.
- In chat, delivery tracking, stock prices and multiplayer games, data must arrive within milliseconds.
- Choosing the right technique saves both server cost and battery.
- Handling lakhs of concurrent connections is a separate scaling problem: you need sticky sessions and a pub/sub backplane.
28.2 How it works
- Short polling: the client sends a request every N seconds. It is simple but wasteful, and data can also arrive late.
- Long polling: the client sends a request and the server holds it until new data arrives or a timeout occurs; the client then immediately sends a new request.
- SSE (Server-Sent Events): a one-way text stream (text/event-stream) from server to client over one HTTP connection; the browser's EventSource reconnects automatically.
- WebSocket: a full-duplex TCP connection (ws:// / wss://) after an HTTP Upgrade handshake; either side can send a message at any time.
- Scaling: keep a map of connected users on each server; if a message is for a user on another server, send it through a Redis Pub/Sub or Kafka backplane.
- Load balancer: use an L4/L7 LB that supports Upgrade and long-lived connections; raise the idle timeout.
- Heartbeat / ping-pong: send a ping every 20-30 sec to detect dead connections.
- Fallback: if corporate proxies block WebSocket, a library like Socket.IO falls back to long polling.
- 1.Short polling: the client sends a request every N sec, often getting an empty reply
- 2.Long polling: the server holds the request until new data arrives, then the client immediately sends a new request
- 3.SSE: a one-way server -> client stream over one HTTP connection, with auto-reconnect
- 4.WebSocket: a full-duplex connection after HTTP Upgrade, messages in both directions
- 5.Scale: gateway servers + connection registry + Redis/Kafka pub/sub backplane
The more real-time and two-way you need, the more you need persistent connections and a backplane
28.3 Tools
| Tool | Type | How it is used |
|---|---|---|
| Socket.IO | Real-time library (Node.js + clients) | Rooms, auto-reconnect and long-polling fallback on top of WebSocket; scales across servers with the Redis adapter. |
| AWS API Gateway WebSocket API | Managed WebSocket (AWS) | AWS manages it; $connect / $disconnect / message routes go to Lambda; you push from the server using connectionId. |
| Pusher / Ably | Hosted real-time service | Publish to channels and the SDK delivers to the client; you do not run WebSocket servers yourself. |
| Azure Web PubSub / SignalR Service | Managed real-time (Azure) | Managed scale-out for ASP.NET SignalR or plain WebSocket clients. |
| Nginx / HAProxy | Reverse proxy / LB | Proxy the WebSocket Upgrade headers; configure long timeouts and sticky sessions. |
| Firebase Realtime Database / Firestore | Realtime BaaS (GCP) | Automatically syncs to subscribed clients as soon as data changes; common in mobile apps. |
28.4 Comparison: WebSocket vs SSE vs Long Polling
| Point | WebSocket | SSE | Long Polling |
|---|---|---|---|
| Direction | Two-way (full duplex) | One-way: server to client | Simulated push; a new request after every response |
| Protocol | ws/wss frames after HTTP Upgrade | Plain HTTP streaming | Normal HTTP request-response |
| Latency | Lowest | Low | Medium; new request overhead on every message |
| Data type | Text + binary | Text only (UTF-8) | Anything over HTTP |
| Reconnect | Write it yourself or use a library (Socket.IO) | Built-in browser auto-reconnect with Last-Event-ID | Naturally, since every cycle is a new request |
| Proxy / firewall | Sometimes blocked | Good, it is normal HTTP | Most compatible |
| Server cost | One connection per user, efficient | One connection per user, efficient | Many requests, higher load |
| Best for | Chat, gaming, collaborative editing | Live score, notification feed, AI token streaming | Old clients, fallback, low-frequency updates |
28.5 When to choose which
- WebSocket: when the client also sends data frequently, such as chat, multiplayer games, or Google Docs-style editing.
- SSE: when you only need updates from the server, such as live cricket score, stock ticker, or ChatGPT-style response streaming.
- Long polling: when WebSocket/SSE is not possible (old proxies) or updates are very infrequent.
- Managed (API Gateway WebSocket, Pusher, Ably): when you have a small team and do not want to scale lakhs of connections yourself.
28.6 Real-world example
Scenario: Live order tracking for food delivery
- The customer opens the order tracking page; the app opens a WebSocket (wss) connection and the LB sends it to one gateway server.
- The gateway server saves a map in Redis: orderId -> server-7, and subscribes to the Redis Pub/Sub channel 'order:123'.
- The delivery partner's app sends GPS location every 4 seconds; the Location Service publishes it to the Redis channel 'order:123'.
- Server-7 receives the message and pushes it to the customer's WebSocket; the bike is seen moving on the map.
- A ping-pong runs every 25 seconds; if the connection drops on a network switch (WiFi to 4G), the client auto-reconnects and fetches the latest state.
- The restaurant dashboard only watches new orders, so a simple SSE stream is enough there.
- At the dinner peak there are lakhs of connections: gateway servers scale horizontally because routing happens through the Redis backplane.
28.7 Interview tips
- Running WebSocket servers on multiple instances without a pub/sub backplane: if user A is on server-1 and user B is on server-2, the message will not reach.
- Leaving the LB/proxy default idle timeout (60 sec) as is: connections will drop again and again; send heartbeats.
- Do not use WebSocket for everything; for one-way updates SSE is simpler and HTTP friendly.
- Interview tip: the answer to 'how will you scale to lakhs of connections' is stateless gateways + connection registry + Redis/Kafka pub/sub.