REST vs WebSocket vs SSE — Real-Time Pattern Decision
Fast recall
Quick revision
Core answer
Last-Event-ID. Use WebSockets when you need full-duplex low-latency messaging — chat, collaborative editing, trading — but accept the stateful connection, custom auth, and horizontal-scaling cost. In 2026, gRPC streaming and HTTP/3 server push nibble at both edges; default to SSE for one-way server→client and WebSocket only when the client must push back in real time.Whether you can match a real-time requirement (notification, chat, dashboard, stock ticker, AI streaming) to the right protocol, and articulate the operational cost of each choice — stateful vs stateless, auth shape, reconnection behaviour, horizontal scaling.
Reaching for WebSockets for every 'real-time' requirement — incurring sticky sessions, Redis pub/sub fan-out, and custom auth — when one-way SSE would be simpler and cheaper. Also the reverse: building long-polling for a collaborative editor where WebSockets are the obvious fit.
Discuss SSE's `Last-Event-ID` resumption, WebSocket frame types and close codes, the STOMP/MQTT-over-WebSocket framing option, how HTTP/2 multiplexing interacts with SSE, sticky-session requirements for WebSocket scaling, and where gRPC bidirectional streaming and HTTP/3 server push displace both.
Interview-ready guide
Interview answer
The protocol depends on who pushes data to whom and how often.
REST with polling or long-polling
- Stateless, CDN-friendly, works through every proxy
- Right for sparse updates with many clients — order status updating every few minutes, low-frequency dashboards
- Latency floor is the poll interval; long-polling closes the gap at the cost of open connections
Server-Sent Events
- A single HTTP response that never closes; server writes
data:frames as events - One-way only — server to client
- Reuses HTTP auth, works through firewalls, and
EventSourceauto-reconnects carryingLast-Event-IDso the server can replay missed events - My default for notifications, live dashboards, progress streams, and LLM token streaming
- Scales by pinning each connection to a node plus a shared bus like Redis pub-sub for fan-out
WebSocket
- Full-duplex; either side can send frames at any time
- Right for chat, collaborative editing, trading, gaming — anywhere the client must push back in real time
- Cost: stateful, needs sticky sessions for horizontal scale, custom reconnect and resubscription logic, custom auth beyond the handshake
- Watch close-code 1006 in metrics — it's the abnormal close signal
When I reach for each
- Notifications, dashboards, LLM streaming → SSE
- Chat, collab, gaming, trading → WebSocket
- CRUD with occasional real-time needs → REST plus a webhook or long-poll
- Internal service-to-service streaming → gRPC bidirectional, not WebSocket
Common mistakes
- Defaulting to WebSocket for everything labelled "real-time" — one-way notifications want SSE
- Short-polling every 500 ms — burn capacity on empty responses
- Putting tokens in the WebSocket URL — leaks into logs
- No shared bus behind scaled SSE/WebSocket — one node can't deliver events produced by another
2026 context
- gRPC bidirectional streaming is the right answer for internal service-to-service, not WebSocket
- HTTP/3 lowers handshake cost of both polling and SSE
- SSE has quietly won the LLM-streaming space; the industry moved away from custom WebSocket protocols there
REST vs WebSocket vs SSE — Real-Time Pattern Decision
Direct Answer
Pick by the direction and duration of the data flow. Use REST (+ long-polling) when updates are sparse and clients are numerous — simplest, cache-friendly, stateless. Use Server-Sent Events (SSE) when the server pushes one-way updates to a browser or HTTP client — feed-style notifications, dashboards, LLM token streaming; it's just HTTP, cache-hostile but firewall-friendly, auto-reconnects, carries Last-Event-ID. Use WebSockets when you need full-duplex low-latency messaging — chat, collaborative editing, trading — but accept the stateful connection, custom auth, and horizontal-scaling cost. In 2026, gRPC streaming and HTTP/3 server push nibble at both edges; default to SSE for one-way server→client and WebSocket only when the client must push back in real time.
Code Example
// 1. REST long-polling — simplest; reconnect loop in user code
async function longPoll(url: string, onMsg: (m: unknown) => void) {
while (true) {
try {
const r = await fetch(url + '?since=' + lastSeen, { signal: abortCtrl.signal });
if (!r.ok) throw new Error('poll failed ' + r.status);
const batch = await r.json();
for (const m of batch.events) onMsg(m);
lastSeen = batch.cursor;
} catch (e) {
await sleep(backoff()); // exponential backoff + jitter
}
}
}
// 2. Server-Sent Events — browser native, auto-reconnects, resumes via Last-Event-ID
const es = new EventSource('/api/v1/notifications', { withCredentials: true });
es.onmessage = e => render(JSON.parse(e.data));
es.addEventListener('order.updated', e => updateOrder(JSON.parse(e.data)));
es.onerror = () => {
// EventSource auto-reconnects; just log
console.warn('SSE reconnecting...');
};
// 3. WebSocket — full duplex; manage reconnect + resubscribe yourself
const ws = new WebSocket('wss://chat.example.com/v1/ws');
ws.binaryType = 'arraybuffer';
ws.onopen = () => ws.send(JSON.stringify({ type: 'auth', token }));
ws.onmessage = ev => dispatch(JSON.parse(ev.data));
ws.onclose = ev => scheduleReconnect(ev.code, ev.reason);
ws.onerror = err => log.error(err);
Common Mistakes & Pitfalls
Reaching for WebSockets for every 'real-time' requirement — incurring sticky sessions, Redis pub/sub fan-out, and custom auth — when one-way SSE would be simpler and cheaper. Also the reverse: building long-polling for a collaborative editor where WebSockets are the obvious fit.
Check your understanding
Answer these without looking back at the article.
- Why is SSE usually a better choice than WebSocket for LLM token streaming?
- How does `Last-Event-ID` make SSE resilient to brief disconnects, and how do you implement it server-side?
- What operational cost does WebSocket incur beyond SSE — sticky sessions, reconnect, auth?
- When does gRPC bidirectional streaming replace WebSocket for internal service-to-service real-time?
Related interview prep categories
1Want a guided curriculum order?
These modules are also sequenced in our flagship backend interview track — open it when you prefer an ordered path instead of browsing by topic.