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.