WebSockets vs Server-Sent Events: When to Use Each?
Compare WebSockets and Server-Sent Events: bidirectional vs one-way streaming, reconnection, and when to choose each.
Expected Interview Answer
WebSockets provide a full-duplex connection where both client and server can send messages at any time over one persistent socket, while Server-Sent Events (SSE) provide a simpler one-way stream where only the server pushes data to the client over a regular HTTP connection.
A WebSocket starts as an HTTP request that upgrades to the “ws://” or “wss://” protocol via a handshake, after which both sides can send binary or text frames independently at any time, making it suited for chat, multiplayer games, or collaborative editing where the client also needs to push data frequently. SSE instead keeps a single long-lived HTTP response open with the “text/event-stream” content type, and the server streams a sequence of newline-delimited events down that one connection while the client uses the native EventSource API, which automatically reconnects and tracks the last event ID for resuming a stream. Because SSE rides on plain HTTP, it works through existing proxies and load balancers without special handling and gets automatic reconnection for free, whereas WebSockets need extra infrastructure support and manual reconnection logic. The deciding factor is direction: if the client only needs to receive updates like notifications, live scores, or price tickers, SSE is simpler and more robust; if the client also needs to send data continuously, WebSockets are necessary.
- WebSockets support true bidirectional, low-latency communication in both directions
- SSE works over plain HTTP with automatic browser-level reconnection via EventSource
- SSE requires no protocol upgrade, simplifying proxy and load balancer configuration
- Choosing the simpler option (SSE) for one-way streams avoids unnecessary complexity
AI Mentor Explanation
WebSockets are like a walkie-talkie link between the pitch and the dugout where either side can speak at any moment without waiting for the other to finish. Server-Sent Events are like a stadium PA system that only the announcer can broadcast on, continuously pushing score updates to everyone listening, with no way for a fan to talk back through it. If players need to relay instructions both ways during play, the walkie-talkie is essential; if fans only need live score updates, the PA system is simpler and just as effective. Picking the wrong one means either overbuilding a one-way broadcast or under-delivering a conversation that needs two-way talk.
Step-by-Step Explanation
Step 1
Client initiates connection
WebSocket sends an HTTP Upgrade request; SSE opens a normal GET request expecting text/event-stream.
Step 2
Connection established
WebSocket completes a protocol handshake to ws://; SSE keeps the HTTP response open and streaming.
Step 3
Data flows
WebSocket frames flow in both directions on demand; SSE events flow one-way from server to client only.
Step 4
Reconnection handling
EventSource auto-reconnects and resumes via Last-Event-ID; WebSockets require the app to detect drops and reconnect manually.
What Interviewer Expects
- Clear articulation of full-duplex (WebSocket) vs one-way (SSE) communication
- Knowledge that SSE runs over plain HTTP while WebSockets require a protocol upgrade
- Awareness of built-in EventSource reconnection vs manual WebSocket reconnection
- Ability to pick the right tool based on whether the client needs to send data
Common Mistakes
- Reaching for WebSockets by default even when the client never sends data
- Not knowing SSE has automatic reconnection built into EventSource
- Assuming SSE supports binary data (it is text-only by spec)
- Forgetting that WebSockets need infrastructure support for the upgrade handshake
Best Answer (HR Friendly)
“WebSockets let the client and server both send messages back and forth freely over one open connection, which is great for things like chat or multiplayer games. Server-Sent Events are simpler and only let the server push updates to the client, which is perfect for things like live notifications or stock tickers where the client never needs to talk back, and they even reconnect automatically if the connection drops.”
Code Example
// WebSocket: client and server both send messages
const socket = new WebSocket('wss://api.example.com/chat')
socket.onmessage = (event) => console.log('received:', event.data)
socket.send(JSON.stringify({ type: 'message', text: 'hi' }))
// Server-Sent Events: server pushes only, client never sends
const stream = new EventSource('/api/notifications')
stream.onmessage = (event) => console.log('notification:', event.data)
stream.onerror = () => console.log('EventSource auto-reconnects')Follow-up Questions
- How do you scale WebSocket connections across multiple server instances?
- What is the Last-Event-ID header used for in SSE?
- Can SSE send binary data, and if not, how would you work around it?
- How would you implement heartbeat/ping-pong to detect a dead WebSocket connection?
MCQ Practice
1. What is the key difference between WebSockets and Server-Sent Events?
WebSockets support full-duplex messaging; SSE only allows the server to push data to the client.
2. What protocol does Server-Sent Events run over?
SSE is just a long-lived HTTP response streamed with the text/event-stream content type.
3. What browser API is used to consume Server-Sent Events?
EventSource is the native API for SSE and includes automatic reconnection support.
Flash Cards
WebSocket direction? — Full-duplex — both client and server can send at any time.
SSE direction? — One-way — only the server pushes data to the client.
SSE transport? — Plain HTTP with a text/event-stream response, no protocol upgrade needed.
SSE reconnection? — Automatic via the native EventSource API, including Last-Event-ID resume.