Real-time Communication
Choosing the right real-time strategy: WebSockets, Server-Sent Events, or Polling for live data updates.
Quick Navigation: WebSockets • SSE • Polling • Scaling • Comparison
When You Need Real-time
- Chat applications: Instant message delivery
- Live dashboards: Real-time metrics and monitoring
- Collaborative editing: Google Docs-style shared editing
- Gaming: Multiplayer game state sync
- Notifications: Push updates to users
- Live feeds: Social media, stock tickers
WebSockets
Full-duplex, persistent connection allowing bidirectional communication between client and server.
How WebSockets Work
1
Client initiates HTTP handshake with Upgrade header2
Server accepts, connection upgraded to WebSocket3
Persistent TCP connection established4
Both sides can send messages anytimeAdvantages
- ✓True real-time: Sub-100ms latency
- ✓Bidirectional: Client and server can initiate
- ✓Efficient: Low overhead after connection
- ✓Binary support: Can send binary data
Disadvantages
- ✗Complex: Connection management, reconnection logic
- ✗Stateful: Harder to scale horizontally
- ✗Proxy issues: Some proxies/firewalls block
- ✗No automatic reconnect: Must implement yourself
🎯 Best For:
Chat apps, multiplayer games, collaborative editing, live trading platforms, high-frequency bidirectional communication.
Server-Sent Events (SSE)
Unidirectional server-to-client streaming over HTTP. Server pushes data to client.
Advantages
- ✓Simple: Built on HTTP, easy to implement
- ✓Auto-reconnect: Browser handles reconnection
- ✓Firewall-friendly: Standard HTTP connection
- ✓Event IDs: Built-in message ordering
Disadvantages
- ✗Unidirectional: Server → Client only
- ✗Connection limit: 6 connections per domain
- ✗Text only: No binary data support
- ✗IE/Edge legacy: No support in old browsers
🎯 Best For:
Notifications, live feeds, stock tickers, progress updates, activity streams, any server-to-client push scenario.
Polling Strategies
Short Polling
Client requests data at fixed intervals (e.g., every 5 seconds).
Pros
- ✓ Very simple to implement
- ✓ Works with any server
- ✓ Easy to debug
Cons
- ✗ High server load
- ✗ Delayed updates (interval bound)
- ✗ Wastes bandwidth when no changes
Long Polling
Client request held open until server has data or timeout.
Pros
- ✓ Near real-time updates
- ✓ Less requests than short polling
- ✓ Widely supported
Cons
- ✗ Server holds connections open
- ✗ Timeout management needed
- ✗ Still more overhead than WebSocket
Scaling Real-time Features
Horizontal Scaling Challenges
- Sticky sessions: Users must connect to same server
- Pub/Sub: Need message broker (Redis, RabbitMQ) for cross-server communication
- Connection limits: Each server has max concurrent connections
Common Solutions
- Redis Pub/Sub: Broadcast messages across server instances
- Socket.io with Redis adapter: Built-in horizontal scaling
- Managed services: Pusher, Ably, AWS AppSync
- Edge workers: Cloudflare Durable Objects, Vercel Edge
Reconnection Strategies
- Exponential backoff: Wait 1s, 2s, 4s, 8s... between retries
- Jitter: Add randomness to prevent thundering herd
- Heartbeats: Detect dead connections early
- Fallback: Switch to polling if WebSocket fails
Comparison Table
| Aspect | WebSocket | SSE | Long Polling |
|---|---|---|---|
| Direction | Bidirectional | Server → Client | Request/Response |
| Latency | Very Low | Low | Medium |
| Complexity | High | Medium | Low |
| Auto-reconnect | Manual | Built-in | N/A |
| Binary Data | Yes | No | Yes |
| Use Case | Chat, Gaming | Notifications | Fallback |
Decision Guide
- 1.Need bidirectional? → WebSockets
- 2.Server-to-client only? → SSE (simpler than WebSockets)
- 3.Low update frequency? → Polling may be sufficient
- 4.Need guaranteed delivery? → Use message queues + acknowledgments
- 5.Don't want infrastructure? → Consider managed services