What is a WebSocket and why HTTP falls short for real-time
HTTP request-response cycle, polling vs push, persistent connections, half-duplex vs full-duplex, latency comparison, use cases for WebSockets
Why HTTP Alone Cannot Do Real-Time
HTTP is a request-response protocol. The client always initiates. The server cannot push data to a client that has not asked for it. For real-time features - chat, live scores, collaborative editing - this creates three bad patterns:
- Short polling: Client asks every N seconds. Wastes bandwidth, adds latency.
- Long polling: Client holds a request open until the server has something. Better, but still one message per round trip.
- Server-Sent Events: One-way server push. Useful but not bidirectional.
WebSockets solve this with a single, persistent, full-duplex TCP connection. Once open, either side can send a frame at any time with no HTTP overhead on each message.
When to Use WebSockets
WebSockets are the right tool when latency matters and data flows in both directions:
- Chat and messaging
- Live dashboards and financial tickers
- Multiplayer games
- Collaborative tools (Figma, Google Docs)
- Real-time notifications
If data only flows server-to-client and you can tolerate occasional drops, Server-Sent Events are simpler. If updates are infrequent and latency tolerances are high, REST polling is fine. Use WebSockets deliberately, not by default.