Backend
WebSockets
A single TCP connection upgraded from HTTP that stays open for full-duplex, low-latency messaging — chat, live dashboards, multiplayer, collaborative editing. Unlike request/response, either side can push at any time. The cost is stateful connections that complicate load-balancing and scaling, usually needing a pub/sub backplane like Redis.
Purpose
WebSockets upgrade a single HTTP connection into a persistent, full-duplex channel so client and server can send messages to each other at any time with minimal overhead. They exist for genuinely interactive, real-time features that request/response cannot serve well.
When to Use It
Chat, live dashboards, multiplayer games, collaborative editing and trading tickers — anywhere the server must push and latency matters, with traffic flowing both ways.
If the client only needs to receive updates, SSE is simpler; if updates are occasional, ordinary polling may be enough.
Trade-offs
A persistent, stateful connection is harder to scale than stateless HTTP: load balancers must hold long-lived connections, and broadcasting across many server instances needs a pub/sub backplane (often Redis). You also own reconnection, heartbeats and back-pressure.
Implementation
Open with the HTTP Upgrade handshake, then exchange framed messages. Authenticate at connect time (a token in the first message), send periodic pings to detect dead peers, and fan messages out between nodes via Redis pub/sub or a managed service. Cap message size and rate to resist abuse.