The Practical Developer

SSE vs WebSockets: When To Pick Each, And Why Most Teams Pick The Wrong One

January 6, 2023 by The Practical Developer

Server-sent events are a 1.5KB drop-in for streaming notifications, progress, and live updates — and they work through every proxy and CDN that already handles HTTP. WebSockets are the right tool for genuine bidirectional, low-latency traffic. Here is the decision tree and the implementation patterns for each.

api

real-time

http

A developer at a keyboard — debugging long-lived connections is exactly this kind of session

A team needs to push live notifications to a logged-in user. Somebody suggests WebSockets. Three weeks later, the team is debugging sticky-session load-balancer config, a custom heartbeat protocol, a reconnection backoff, and why the corporate proxy is silently dropping the upgrade request. Meanwhile, the original requirement — “send a JSON message from server to browser every few seconds” — is something Server-Sent Events would have solved with an HTTP GET and 30 lines of code.

WebSockets are the right tool for some workloads. They are over-applied. SSE is the right tool for most server-push use cases, and most teams do not even know it exists. This post is the decision criteria, the SSE implementation patterns that actually scale, and the WebSocket gotchas you only learn the hard way.

The decision in one paragraph

Use SSE if data flows mostly server → client, you want a long-lived stream, you do not need binary frames, and you want everything to ride over plain HTTP/1.1 or HTTP/2. Use WebSockets if you need genuinely bidirectional traffic with sub-100ms latency in both directions (collaborative editing, multiplayer games, voice signaling). For everything in between — chat, dashboards, notifications, build progress, AI streaming — SSE is the right default.

What SSE is

A standard HTTP response with Content-Type: text/event-stream. The connection stays open. The server writes records like:

event: notification
data: {"id":1,"text":"hello"}

event: progress
data: {"percent":42}

(Two newlines between records — that is the framing.) The browser has a built-in API:

const es = new EventSource('/api/stream');
es.addEventListener('notification', (e) => {
  const data = JSON.parse(e.data);
  console.log(data);
});
es.onerror = () => console.log('reconnecting...');

That is the entire client-side. Reconnection is automatic. Last-Event-ID is sent on reconnect so the server can resume from where it left off. No custom protocol, no library.

SSE on the server in Node.js

app.get('/api/stream', async (req, res) => {
  res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache, no-transform',
    'Connection': 'keep-alive',
    'X-Accel-Buffering': 'no', // disable nginx buffering
  });

  // Send the headers immediately so the browser knows we are streaming.
  res.flushHeaders();

  // Optional: replay since the client's last event id.
  const lastId = req.headers['last-event-id'];
  for (const event of getEventsSince(lastId)) {
    res.write(formatSSE(event));
  }

  // Subscribe to new events.
  const unsubscribe = pubsub.on('user.' + req.user.id, (event) => {
    res.write(formatSSE(event));
  });

  // Heartbeat to keep proxies from idling out the connection.
  const heartbeat = setInterval(() => res.write(': ping\n\n'), 25_000);

  // Clean up on disconnect.
  req.on('close', () => {
    clearInterval(heartbeat);
    unsubscribe();
  });
});

function formatSSE({ id, event, data }: { id: string; event: string; data: any }) {
  return `id: ${id}\nevent: ${event}\ndata: ${JSON.stringify(data)}\n\n`;
}

Three things make this production-ready: heartbeat (some proxies kill idle connections after 30 seconds), X-Accel-Buffering: no (tells nginx and similar to flush on every write), and Last-Event-ID handling (so reconnects do not lose messages).

What SSE gets you for free

  • Reconnection. Browsers reconnect on drop with backoff; you get this without writing it.
  • HTTP semantics. Auth headers, cookies, CORS — same as any other request. No custom upgrade handshake.
  • Proxy-friendly. Plain HTTP. Works through every reverse proxy, CDN, and corporate gateway. WebSockets often do not.
  • HTTP/2 multiplexing. Multiple SSE streams share one TCP connection.
  • Standard tooling. curl --no-buffer https://your-api/stream works for debugging.

The cost: server → client only. The client cannot push back over the same channel — it has to make a separate POST. For most “live updates” this is a feature, not a bug.

SSE limitations to know about

Browser connection limits. HTTP/1.1 caps at 6 connections per origin. If your app opens an SSE on every page, the user has 5 left for everything else. HTTP/2 fixes this — make sure your server runs HTTP/2 if you have many SSE connections per user.

No binary frames. SSE is text. Base64-encode if you need to push binary, or use WebSockets.

Some old proxies buffer. A misconfigured nginx or some corporate firewalls will buffer up the entire response. The X-Accel-Buffering: no header handles nginx; for others, you may need to send chunked padding (: followed by a long string) periodically to force a flush.

Where WebSockets are the right answer

Five workloads where SSE is genuinely insufficient:

  1. Collaborative editing (Figma, Notion). Sub-100ms bidirectional latency for cursor positions, edits.
  2. Real-time multiplayer. Games where the server sends 30 frames per second and the client sends inputs at the same rate.
  3. Voice / WebRTC signaling. The signaling channel needs full duplex during call setup.
  4. High-frequency client → server traffic. Custom IoT, trading interfaces, live drawing apps.
  5. Subprotocols you actually need. STOMP over WebSocket, etc.

For these, WebSockets are correct. The cost is an upgrade handshake, sticky sessions or a pub/sub fanout layer, custom heartbeats and reconnection logic, and proxy / CORS quirks.

WebSocket gotchas

If you do go WebSocket, know what you are signing up for:

Sticky sessions or shared state. A WebSocket lives on one server. If the user reconnects to a different instance, that instance does not have their state. Either use sticky sessions (load balancer routes the same client to the same backend) or push messages through a pub/sub layer (Redis, NATS) so any instance can deliver to any client.

Heartbeat and timeout. Browsers and proxies kill connections that look idle. Send a ping/pong every 30s. The browser’s built-in ping is not exposed to your code, so you have to roll application-level pings.

Backpressure. A slow client makes the server’s per-connection write buffer grow. Without limits, one slow client can OOM the process. ws library has maxPayload; ensure you also bound the outgoing queue length.

Reconnection logic. Unlike SSE, you write it. Exponential backoff with jitter, resume protocol if you have one, message buffering during disconnect.

Origin / CORS confusion. WebSockets do not respect normal CORS. Validate Origin server-side or any browser tab on any origin can connect.

Streaming AI responses: SSE is the right pick

The “AI app streaming tokens” use case is where SSE has quietly won. OpenAI, Anthropic, and most AI-app templates stream completions over SSE. The reasons fit the SSE strengths:

  • One-way (server → client).
  • Fine-grained, frequent messages (one per token).
  • Built-in reconnection / resume not needed (clients usually retry from scratch).
  • No binary content.
  • Plays well with HTTP semantics for auth.

The Vercel AI SDK, LangChain, and FastAPI all default to SSE for this reason. If you are building an AI feature today, SSE is the path of least resistance.

Scaling SSE

A Node.js process can hold tens of thousands of open SSE connections (each is just an open TCP socket; memory per connection is small). What scales it is the fan-out — how the server learns of new events to send.

Three patterns, in order of complexity:

  1. In-process pub/sub. All connections live on one process; events are emitted in the same process. Up to ~10k connections per instance. Good for prototypes.
  2. Redis pub/sub. Multiple SSE servers each subscribe to a Redis channel. When an event fires anywhere, every server gets it and forwards to its subscribed clients. Scales to ~100k connections across instances.
  3. NATS / Kafka topic per user. For very large fan-outs (millions of clients), use a system designed for it.

Pattern 2 covers almost everyone.

The takeaway

SSE is the underused server-push primitive. It works through every proxy, has a built-in client API with automatic reconnection and message resume, and scales to hundreds of thousands of concurrent connections with stock infrastructure. WebSockets are the right tool for genuinely bidirectional, low-latency, possibly binary traffic — but most teams reaching for them only need SSE.

The next time somebody says “we need WebSockets,” ask: does the client need to push as often as the server does, with sub-100ms latency? If yes, WebSockets. If no, SSE.

A note from Yojji

The kind of architecture decision that saves three weeks of infrastructure debugging — picking SSE over WebSockets when the workload is one-directional, picking WebSockets when it really is bidirectional — is the kind of judgment Yojji’s senior engineers bring to client work.

Yojji is an international custom software development company founded in 2016, with offices in Europe, the US, and the UK. Their dedicated teams ship across the JavaScript ecosystem (React, Node.js, TypeScript) and the major cloud platforms (AWS, Azure, GCP), including the real-time backend work that decides whether a feature feels live or laggy.