When would you use WebSockets, SSE, or long-polling instead of plain HTTP?

Question

IT Interview Practice · Accepted Answer

Plain HTTP is **request/response**: the client asks, the server answers, done. That's a poor fit for **real-time** features (chat, live dashboards, notifications, collaborative editing) where the *server* needs to push data whenever it has something new. The options are ways to get around HTTP's client-initiated model, along a spectrum of complexity:

```text
Long-polling   client ──req──▶ server ...holds... ──resp──▶ then immediately re-asks
               (near-real-time over plain HTTP; one message per held request)

SSE            client ──req──▶ server ═══stream of events═══▶ (one-way, server→client)
               (HTTP-based, text, auto-reconnect; NO client→server on same channel)

WebSocket      client ──handshake──▶ server ══full-duplex, both directions══▶
               (persistent TCP; low overhead; binary or text; you build the rest)
```

**Long-polling** is the fallback that works everywhere: the client makes a normal request the server holds open until it has data, then the client immediately re-requests. It approximates push over plain HTTP but wastes a request cycle per message and adds latency.

**SSE (Server-Sent Events)** is a lightweight, standardized **one-way** stream (server → client) over a single long-lived HTTP response. It's ideal when only the server pushes — live feeds, notifications, progress, streaming LLM tokens. It's simple, runs over normal HTTP/2 (no special infrastructure), and auto-reconnects. The limit: it's one-directional and text-only.

**WebSockets** upgrade a single HTTP connection into a persistent, **full-duplex** TCP channel where both sides send anytime with minimal per-message overhead. Use it for genuinely bidirectional, low-latency interaction: chat, multiplayer games, collaborative editors, trading. The cost is operational — it's a stateful connection that proxies, load balancers, and autoscalers must be configured for, and you must build reconnection, heartbeats, and backpressure yourself.

**Rule of thumb:** default to plain HTTP; use **SSE** for server→client streaming; reach for **WebSockets** only when you truly need bidirectional real-time; keep **long-polling** as the universal fallback.

## Why it matters

Choosing a real-time transport is a classic senior design decision where the naive answer ("just use WebSockets for everything") is usually wrong. Interviewers want to see that you match the tool to the *communication pattern* — one-way vs bidirectional, latency needs, message volume — and that you weigh the **operational cost** of stateful, long-lived connections: sticky sessions, scaling, proxy timeouts, and reconnection logic. Recognizing that SSE often covers "server pushes updates" more simply than WebSockets, and that long-polling remains a robust fallback, signals real production experience rather than reaching for the flashiest option.

Why it matters

Related questions