Real-Time Apps: Polling, WebSockets and SSE

1. Short polling

Short polling means the client sends a normal request again and again, every N seconds, to ask "anything new?":

setInterval(async () => {  const res = await fetch("/api/notifications?since=" + lastSeen);  render(await res.json());}, 5000);

• ✅ Very simple. It works everywhere, with any backend, load balancer and CDN.
• ❌ Wasteful. Most requests return nothing.
• ❌ Delay. On average, updates arrive half an interval late.

Quick maths (lesson 10): 1 million users polling every 5 seconds = 200,000 requests per second, mostly returning "nothing new". That is a lot of server work that gives almost no value.

Good for: low-frequency updates, a small number of users, checking a background job's status ("Is my report ready?"), or dashboards refreshed every minute.

2. Long polling

With long polling, the client sends a request, and the server holds it open until there is news or a timeout (say 30 seconds). A timeout is a set time limit after which the server stops waiting. Then the client immediately sends another request.

• ✅ Near real-time, using plain HTTP, so it works through almost every proxy and firewall.
• ✅ Much less wasted traffic than short polling.
• ❌ Each waiting client holds a request open on the server. With thread-per-request servers (lesson 4), this means one thread per waiting user, which is costly. Event-loop servers (Node.js, NGINX) and servers with very light threads (Go) handle this much better.
• ❌ There is still extra work from reconnecting after every message. You also need care so that messages stay in order and none are missed.

Good for: a fallback when WebSockets are not possible, and moderate real-time needs. Early versions of many chat apps used long polling.

3. Server-Sent Events (SSE)

SSE is a standard way for a server to send a stream of events to a browser. The client opens one long-lived HTTP connection, and the server streams events down it whenever it wants. It is one-way: server to client.

GET /eventsAccept: text/event-streamHTTP/1.1 200 OKContent-Type: text/event-streamid: 101event: order_statusdata: {"orderId": 5521, "status": "out_for_delivery"}id: 102event: order_statusdata: {"orderId": 5521, "status": "delivered"}

In the browser, you only need a few lines. EventSource is the built-in browser class for SSE:

const events = new EventSource("/events");events.addEventListener("order_status", (e) => {  const update = JSON.parse(e.data);  showStatus(update.status);});

• ✅ Simple. It is plain HTTP with a text format. It works with normal load balancers, auth cookies and HTTP/2.
• ✅ Automatic reconnect built in. The browser reconnects and sends Last-Event-ID, so the server can resume from where the client left off.
• ✅ Great for streaming text.
• ❌ Server → client only. To send data up, the client uses normal HTTP requests (which is often perfectly fine).
• ❌ Text only (binary data must be encoded as text).
• ❌ The browser's EventSource can only use GET and cannot set custom headers (such as Authorization). Cookies work. Libraries that use fetch can remove this limit.
• ❌ With HTTP/1.1, browsers allow only about 6 connections per domain, and each SSE stream uses one. HTTP/2 multiplexing (many streams over one connection) removes this problem.

Good for: live feeds, notifications, sports scores, stock tickers, progress bars, deployment logs, and streaming AI responses word by word.

4. WebSockets

A WebSocket is a connection that stays open and lets both sides send messages at any time. It starts as an HTTP request that asks to upgrade the connection (switch to another protocol). Then it becomes a persistent, two-way channel:

const ws = new WebSocket("wss://chat.example.com/ws");ws.onmessage = (e) => handle(JSON.parse(e.data));ws.send(JSON.stringify({ type: "message", to: "ravi", text: "hi" }));

• ✅ True two-way, low-latency communication, with very little overhead per message after setup.
• ✅ Supports binary data (games, audio).
• ❌ Stateful connections. "Stateful" means the server must remember each open connection. This makes scaling, deploys and load balancing harder (see below).
• ❌ Some proxies and corporate firewalls interfere with long-lived connections. Use wss:// (WebSocket over TLS, the encrypted version), which usually gets through.
• ❌ No built-in reconnect or resume. You must build heartbeats, reconnection and message recovery yourself (or use a library such as Socket.IO, which adds these features).

Good for: chat, multiplayer games, collaborative editors, live trading screens, and anything where both sides send frequent messages.

Comparison

Scaling persistent connections

With SSE and WebSockets, each user keeps a connection open to one specific server. This creates new design problems.

1. Connection capacity. A well-tuned server can hold tens or even hundreds of thousands of mostly idle connections. But you must tune the file-descriptor limit (the number of open connections and files the operating system allows), the memory per connection, and the timeouts. Estimate it: 10 million online users ÷ 100k connections per server = 100 gateway servers.

2. Routing messages to the right server. User A is connected to gateway 1. User B is connected to gateway 7. A gateway is a server that holds the open connections. When A sends B a message, how does it reach gateway 7?

The common pattern:

• Gateways only manage connections.
• A pub/sub system (publish/subscribe: senders publish messages and subscribers receive them; for example Redis Pub/Sub, NATS, Kafka) passes messages between gateways.
• A presence registry records which user is connected to which gateway.

We'll design this fully in the chat-system case study (lesson 63).

3. Load balancing. Balancing connections evenly matters more than balancing requests. Use least-connections balancing (send new connections to the server with the fewest). Remember that a new server starts empty. Long-lived connections do not move to it on their own.

4. Deploys and restarts. Restarting a gateway drops every connection on it. Clients must reconnect with backoff and random jitter. Backoff means waiting longer after each failed try. Jitter means adding a random delay. Without them, thousands of clients reconnecting at the same instant will create a stampede (Part 7). Drain connections gradually during deploys, which means closing them a few at a time.

5. Heartbeats. A heartbeat is a small message sent again and again to show the connection is alive. Send ping/pong messages every 20–60 seconds. They detect dead connections (like a phone that went into a tunnel), and they stop proxies from closing "idle" connections.

6. Do not lose messages. Connections will drop. So:

• give messages sequence numbers or IDs,
• on reconnect, the client says "the last thing I got was #1041", and the server replays what was missed from storage,
• store messages durably first, then push them. The push is a notification, not the only copy.

Beyond these four

• Webhooks: server-to-server push. You give another service a URL, and it calls that URL when something happens, for example "when a payment succeeds" (lesson 34 covers making them reliable).
• Mobile push notifications (APNs for Apple, FCM for Android): reach phones even when the app is closed (lesson 62).
• WebRTC: a browser technology for peer-to-peer audio and video, where users connect directly (lesson 2 explains UDP, which it often uses).
• MQTT: a lightweight publish/subscribe protocol for IoT (Internet of Things) devices such as sensors.
• WebTransport: a newer option for low-latency, two-way communication. It is built on HTTP/3, which runs on QUIC (a modern transport protocol).

Choosing