Real-time Communication Patterns#
WebSockets
- How it works: Full-duplex TCP connection, both client/server can send data anytime
- Key differentiator: True bidirectional real-time communication
- Ideal for: Chat apps, live gaming, collaborative editing, live trading
- Trade-off: More complex, requires connection management
Server-Sent Events (SSE)
- How it works: Server pushes data to client over single HTTP connection
- Key differentiator: One-way (server→client), simpler than WebSockets
- Ideal for: Live feeds, notifications, stock tickers, live scores
- Trade-off: Unidirectional, less efficient than WebSockets for two-way
Long Polling
- How it works: Client makes HTTP request, server holds it open until data available
- Key differentiator: Uses standard HTTP, appears real-time but isn’t
- Ideal for: Simple notifications, low-frequency updates
- Trade-off: Higher latency, resource intensive on server
Short Polling
- How it works: Client repeatedly requests server at regular intervals
- Key differentiator: Simplest to implement, most reliable
- Ideal for: Status updates, low real-time requirements
- Trade-off: High latency, wasteful (many empty responses)
WebRTC (real-time communication)
- How it works: Peer-to-peer direct connection after initial signaling
- Key differentiator: No server in data path, ultra-low latency
- Ideal for: Video calls, voice chat, file sharing, gaming
- Trade-off: Complex setup, NAT traversal issues
Latency ranking: WebRTC < WebSockets < SSE < Long Polling < Short Polling