Long-Polling, WebSockets, and Server-Sent Events

Standard HTTP is pull-based: the client sends a request, the server responds. There's no mechanism for the server to push new data to the client unprompted. For real-time use cases (chat, live stock prices, notifications, collaborative editing), the client needs to receive updates immediately when they happen — not wait for the next poll.

Three solutions exist, each with different trade-offs: Long-Polling, Server-Sent Events (SSE), and WebSockets.

Client sends an HTTP request to the server. The server holds the connection open (doesn't respond) until new data is available or a timeout occurs. When new data arrives, the server responds with it. The client immediately sends a new request. This creates a cycle where the connection is always open from the client side.

Pros: works with existing HTTP infrastructure (proxies, firewalls, CDNs). No special protocol. Cons: repeated connection setup overhead. If the server has no data, clients are stuck waiting. Overhead of HTTP headers on every cycle. High server memory usage (one open connection per waiting client).

Use case: chat systems before WebSockets were universal (Dropbox change notifications, older Facebook chat). Still used where WebSocket infrastructure is unavailable.

A standardized HTTP streaming protocol. The client opens a persistent HTTP connection using EventSource API. The server sends text/event-stream responses continuously — each event is a text message with data and an optional id. The connection stays open indefinitely. The client handles events via JavaScript event listeners.

Pros: simpler than WebSockets, uses regular HTTP (works through all proxies and load balancers), automatic reconnection built in, event IDs allow resuming after reconnect. Native browser support. Cons: unidirectional — server pushes to client only; client cannot send data over the SSE connection (must use a separate HTTP request).

Use case: live sports scores, stock prices, server-side progress bars, Twitter's streaming API, GitHub's live event stream. Any scenario where the server pushes updates but the client doesn't need to send back real-time data.

WebSockets provide a full-duplex (bidirectional) persistent connection between client and server. The connection starts as HTTP and upgrades to the WebSocket protocol via an HTTP handshake (Upgrade: websocket header). After the upgrade, both client and server can send messages at any time independently.

The connection is a persistent TCP socket — messages are framed (not full HTTP requests). Extremely low latency for messages after the initial connection. Efficiently handles high-frequency bidirectional data.

Pros: full bidirectional communication, very low per-message overhead (framing without HTTP headers), built-in support in all modern browsers, natural for real-time data. Cons: stateful connections (harder to load balance — need sticky sessions or a message broker), doesn't cache (CDNs can't cache WebSocket traffic), more complex server infrastructure (connection management at scale).

Use case: chat (Slack, Discord, WhatsApp Web), online multiplayer games, collaborative document editing (Google Docs), real-time trading dashboards, live cryptocurrency prices.

Use Long-Polling when: real-time but infrequent updates are needed, you want maximum compatibility with old infrastructure, and you can tolerate the inefficiency of repeated connections. Example: email notification checks every 30 seconds.

Use SSE when: the server pushes continuous data to many clients, no client-to-server real-time data needed, and simplicity is preferred. Example: live event feed, stock ticker, deployment progress.

Use WebSockets when: true bidirectional real-time communication is needed. Example: chat, collaborative editing, gaming.

Rule of thumb for interviews: chat and collaboration → WebSockets. Live feed/notifications where clients only read → SSE. Fallback for old systems → Long-Polling.