Real-time Communication: WebSockets, SSE & Polling
Real-time features require choosing the right transport based on directionality, latency needs, scaling complexity, and operational cost. WebSockets offer full bidirectional communication but are stateful and harder to scale. Server-Sent Events provide simple unidirectional push with built-in reconnection. Polling is easiest but least efficient.
WebSockets = a phone call (both can talk anytime). SSE = a radio broadcast (server talks, you listen). Polling = repeatedly calling to ask 'anything new?' The best choice depends on how often each side needs to speak and how reliably the connection must stay open.
1WebSockets
Persistent, bidirectional, full-duplex connection. Excellent for chat, collaborative editing, and multiplayer games. Requires careful connection management, reconnection logic, and horizontal scaling (often with Redis Pub/Sub).
useEffect(() => {
const ws = new WebSocket(WS_URL);
ws.onmessage = (e) => handleMessage(JSON.parse(e.data));
return () => ws.close();
}, []);2Server-Sent Events (SSE)
Unidirectional server-to-client streaming over HTTP. Simpler than WebSockets with built-in reconnection and event IDs. Ideal for notifications, live feeds, and progress updates.
3Polling Strategies
Short polling (fixed interval) is simple but wasteful. Long polling holds the connection open until data arrives. Use only when real-time requirements are relaxed.
4Scaling, Reconnection & Consistency
Plan for reconnection with exponential backoff + jitter. Use message ordering, idempotency, and client-side reconciliation to handle missed or out-of-order events.
| Property | WebSockets | SSE | Polling |
|---|---|---|---|
| Latency | Very Low | Low | Medium-High |
| Scaling | Complex (stateful) | Easier (HTTP) | Simple |
| Best For | Chat, games, collaboration | Notifications, live feeds | Low-frequency updates |
| Direction | Bidirectional | Server → Client | Request/Response |
WebSockets
Latency
Very Low
Scaling
Complex (stateful)
Best For
Chat, games, collaboration
Direction
Bidirectional
SSE
Latency
Low
Scaling
Easier (HTTP)
Best For
Notifications, live feeds
Direction
Server → Client
Polling
Latency
Medium-High
Scaling
Simple
Best For
Low-frequency updates
Direction
Request/Response
Common questions
- ›“When would you choose WebSockets over SSE?”
- ›“How do you handle reconnection in real-time features?”
- ›“How do you scale WebSockets horizontally?”
- ›“What are the trade-offs between polling and push-based solutions?”
What interviewers look for
- Clear understanding of directionality and latency needs
- Knowledge of reconnection, ordering, and idempotency
- Scaling awareness (Redis Pub/Sub, sticky sessions)
- Balanced trade-off reasoning
Short answer (60 sec)
Use WebSockets for bidirectional low-latency needs (chat, games). SSE for simple server push (notifications, feeds). Polling as a simple fallback. Always implement reconnection with backoff + jitter and ensure event ordering/idempotency.
Detailed answer (senior level)
WebSockets provide true bidirectional communication but require stateful scaling and reconnection logic. SSE is simpler for unidirectional push with built-in reconnection. Polling is easiest but inefficient. For production, combine with deduplication, optimistic updates, and client-side reconciliation to handle disconnects and out-of-order events gracefully.
- Using WebSockets when SSE would suffice
- No reconnection strategy (users lose updates on disconnect)
- Ignoring message ordering and idempotency
- Creating retry storms during outages
- Scaling WebSockets without proper pub/sub backend
- ✓WebSockets for bidirectional real-time
- ✓SSE for simple, reliable server push
- ✓Polling as fallback or for low-frequency updates
- ✓Always implement reconnection with backoff + jitter
- ✓Ensure event ordering and idempotency on client
- ✓Plan for horizontal scaling from day one
- ✓Choose transport based on direction, latency, and complexity
Related web fundamentals topics
Continue with closely related browser and frontend engineering concepts.