WebSocket vs SSE — Detailed Technical Comparison
Fast recall
Quick revision
Core answer
Depth of understanding beyond the simple 'WebSocket is bidirectional' answer.
Overlooking that SSE is just a long-lived HTTP response — it reuses existing HTTP infrastructure with no special proxy configuration needed.
Mention HTTP/2 server push vs. SSE, Spring's SseEmitter or WebFlux ServerSentEvent, and that SSE has a built-in event ID and retry mechanism.
Interview-ready guide
Interview answer
For most applications that call themselves "real-time," the actual requirement is server-to-client push — the server has new data and needs to send it without the client explicitly requesting it. SSE handles this more simply than WebSocket, and understanding the difference guides the right architecture choice.
Server-Sent Events — the simpler choice for unidirectional push:
- SSE works as a persistent HTTP response, which means it works through every proxy, load balancer, and CDN you already have — no infrastructure changes needed
- Built-in reconnection: the
retry:field in the SSE response specifies the reconnect interval, and the browser automatically sendsLast-Event-IDto resume from the last received event; WebSocket applications must implement this from scratch - The Spring implementation is a
SseEmitterreturned from a normal controller method, captured by your existing HTTP monitoring infrastructure
WebSocket — necessary for continuous bidirectional streaming:
- WebSocket is the right choice only when the client needs to continuously stream data upstream through the same persistent connection: chat input, collaborative editing where every keypress matters, game state at 60fps
- If the client sends data occasionally — button clicks, form submissions — REST POST alongside SSE handles this without WebSocket infrastructure
Key technical differences:
- SSE supports only text/event-stream; binary payloads require base64 encoding with ~33% overhead; WebSocket carries binary data natively with opcode 0x2
- Under HTTP/1.1, browsers cap SSE at six connections per origin; under HTTP/2 this limit disappears through multiplexing; WebSocket connections have no per-origin limit under either HTTP version
I recommend the REST+SSE hybrid as the default for most "real-time" features — SSE for push, REST for mutations — and only WebSocket when continuous bidirectional streaming at sustained rates genuinely justifies the broker infrastructure and session management complexity.
WebSocket vs SSE — Detailed Technical Comparison
Direct Answer
WebSocket provides full-duplex communication over a single TCP connection; SSE is a one-way server-to-client stream over HTTP. SSE is simpler, works natively over HTTP/2 with multiplexing, and auto-reconnects. WebSocket has lower latency for bidirectional use cases but requires more infrastructure support.
Common Mistakes & Pitfalls
Overlooking that SSE is just a long-lived HTTP response — it reuses existing HTTP infrastructure with no special proxy configuration needed.
Check your understanding
Answer these without looking back at the article.
- How do you implement SSE in Spring Boot using SseEmitter?
- What is the HTTP/2 browser connection limit and how does it affect SSE?
- When would you combine SSE with a regular REST endpoint instead of using WebSocket?
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.