WebSockets & Server-Sent Events

What is it?

📞 Think of it like different ways to stay updated:

Normal HTTP is like texting someone "Any news?" every 5 minutes. Polling — inefficient if nothing changed.

Server-Sent Events (SSE) is like subscribing to a news channel — they push notifications TO you whenever something happens. One-way: server → client.

WebSockets is like a phone call — once connected, BOTH sides can talk at any time. Two-way: client ↔ server simultaneously.

In regular HTTP, the client asks, server responds, connection closes. But what if you need REAL-TIME updates? (Chat messages, live scores, stock prices, Uber driver location). You need the server to push data without the client constantly asking.

💡 Simple Summary: HTTP = client asks every time. SSE = server pushes to client. WebSocket = both talk freely, anytime, like a phone call.

How it works — Like you're watching it happen

WebSockets:

Server-Sent Events (SSE):

❓ But wait — why not just use WebSockets for everything?

WebSockets are MORE complex — they need special server infrastructure, don't work with standard HTTP caching/CDN, and are harder to scale (load balancers need sticky sessions). If you ONLY need server→client updates (stock prices, notifications, live scores), SSE is simpler, works over standard HTTP, auto-reconnects, and is supported by all browsers. Use WebSockets only when the client ALSO needs to send frequent data (chat, multiplayer games).

Why should you care? (Interview perspective)

Key Things to Remember

Real Examples You Use Daily

💬 WhatsApp Web/Slack — Uses WebSockets. When someone sends you a message, the server instantly pushes it to your open WebSocket connection. You also send messages through the same connection. Two-way, real-time.

📊 Zerodha/Groww (Stock trading) — Live stock prices use WebSockets or SSE. Prices change every millisecond — polling would be too slow and expensive. The server streams price updates to your screen in real-time.

🚗 Uber driver tracking — When you're watching your driver approach on the map, that's live location being pushed to your phone. The driver's app sends position updates (WebSocket up), Uber pushes them to your map (WebSocket down).

🔔 Instagram notifications — When someone likes your post, you get an instant notification. The server pushes this via a persistent connection (SSE or WebSocket) rather than your app constantly asking "any new notifications?"

Common Mistakes in Interviews

❌ Using WebSockets when SSE is enough — "For live cricket scores, I'd use WebSockets." But cricket scores are ONE-WAY (server → client). SSE is simpler, auto-reconnects, and works over standard HTTP infrastructure. Use WebSocket only when the CLIENT also needs to send frequent messages.

❌ Forgetting the scaling problem — With 1M WebSocket connections, if user A (on Server 1) sends a message to user B (on Server 3), how does Server 3 know? You need Redis Pub/Sub or a message broker between servers.

❌ Not mentioning heartbeats — Without ping/pong, a dead connection sits silently. The server thinks the client is still connected, wasting resources. Heartbeats detect dead connections.

❌ Ignoring reconnection logic — Networks are flaky. Mobile users switch between WiFi and 4G. Your WebSocket WILL disconnect. You need exponential backoff reconnection and message replay (what did I miss while disconnected?).

❌ Saying "polling is always bad" — For dashboards updating every 5 minutes, simple polling is fine and SIMPLER to build. WebSocket overhead isn't worth it for infrequent updates.

🎯 Interview One-Liner

"WebSockets provide full-duplex, persistent connections for bidirectional real-time communication like chat, while SSE offers simpler one-way server-to-client streaming over standard HTTP — and the choice depends on whether the client needs to frequently send data back or just receive updates."

Interview Q&A