# WebSocket vs SSE vs Long Polling: Real-Time Frontend Choices

Source: https://www.techinterview.org/post/3233475142/websocket-sse-long-polling-comparison/
Updated: 2026-07-12 · techinterview.org

Choosing the right real-time mechanism is a frontend system design question that comes up routinely in senior interviews. WebSocket is the default for most engineers, but it is not always the right choice. Understanding the tradeoffs is professional baseline.

## The three main options

### WebSocket

Persistent bidirectional TCP connection upgraded from HTTP. Both client and server can send messages at any time.

### Server-Sent Events (SSE)

HTTP-based one-way (server → client) streaming. Connection stays open; server pushes events as text-stream.

### Long polling

Client makes HTTP request; server holds it open until data is ready (or timeout); response triggers next request.

## When to use WebSocket

- Truly bidirectional communication (chat, gaming)

- Low latency requirements

- Many small messages per second per connection

- You can manage state on a stateful server

Examples: Slack messaging, Figma cursors, multiplayer game state.

## When to use SSE

- Server-to-client only (notifications, dashboards, AI streaming responses)

- Want to reuse HTTP infrastructure (proxies, caches, retries)

- Simpler than WebSocket for one-way

- Built-in browser auto-reconnect

Examples: stock tickers, live blog updates, LLM streaming responses (ChatGPT-style).

## When to use long polling

- Infrequent updates (seconds to minutes)

- Backward compat with environments that block WebSocket

- Simplicity matters more than latency

- Stateless backend

Examples: legacy systems, low-priority background updates.

## Performance comparison

| Mechanism | Latency | Server CPU | Server Memory | Bandwidth |
| --- | --- | --- | --- | --- |
| WebSocket |