WebSockets vs Server-Sent Events: when each one wins

WebSockets get reached for by reflex any time a feature needs realtime behavior. Most of the time that reflex is wrong. Server-Sent Events are simpler, cheaper to run, easier to debug, and a much better fit for the broadcast-shaped problems that account for the majority of realtime features people ship: notifications, live counters, status feeds, model-output streaming.

The actual rule: pick SSE when the server is the source of truth and clients only listen. Pick WebSockets when the protocol needs to be symmetric, both sides talk, both sides matter, latency is critical, and you can absorb the operational tax that comes with persistent bidirectional connections.

What SSE buys you

• One direction, one TCP connection, plain HTTP/2 underneath. Works through every proxy and CDN you already run.
• Auto-reconnect with Last-Event-ID is part of the spec. The browser does the retry math; you don't write it.
• Standard HTTP auth, CORS, caching headers. Nothing new to learn for your edge layer.
• Cheap to scale horizontally. Each connection is a long-lived GET; you can shed traffic with the same load balancer you already use.

When WebSockets are the right call

Three patterns force WebSockets and nothing else fits cleanly: collaborative editing where every keystroke flows both ways, multiplayer or gameplay where input latency below 100ms matters, and any protocol where the client publishes high-frequency events back to the server (mouse position, presence, cursor sharing). For these, SSE plus separate POST requests adds round-trip overhead you can measure.

The cost is operational. WebSockets bypass your normal HTTP infrastructure: special CDN config, sticky load balancing, custom reconnect logic, and a separate scaling profile because each connection occupies a worker. Plan for that before reaching for the protocol.

The hybrid we usually end up with

On most production stacks we ship, SSE handles the listener-shaped 90% (live dashboards, notification feeds, LLM token streaming) and a small WebSocket service handles the symmetric 10% (collaborative cursors, room presence). Mixing the two is cheaper than forcing everything into one protocol because each side stays simple.

The mistake is committing to WebSockets up front for a feature that turns out to be one-directional. Reverting is expensive: you've already paid for the sticky load balancer and the reconnect library. SSE first, WebSockets when you actually need them.