WebSockets
Async CommunicationA full-duplex, persistent connection over a single HTTP-upgraded TCP socket — the most powerful but most stateful/expensive way to push real-time updates.
HTTP is fundamentally request/response — the server can't push data unless the client asks. WebSockets solve this by upgrading a single HTTP connection (via the `Upgrade: websocket` handshake) into a long-lived, full-duplex TCP-like channel: either side can send a message at any time with minimal per-message framing overhead. This makes WebSockets the right tool when the client and server need to talk back and forth in near real time — chat, multiplayer games, collaborative editors, live trading terminals — not just when the server needs to push to an otherwise-idle client.
How it connects
WebSockets as the source, with the components it typically interacts with.
- → Load Balancer: Long-lived WebSocket connections need L4/sticky-session-aware load balancing so a client's connection consistently reaches the same server instance.
- → Message Queues & Event Streaming: A pub/sub broker fans out realtime messages to all server instances holding a relevant subscriber's connection, since a single server no longer holds every connection.
- → Caching: Presence/connection-routing metadata (which server holds which socket) is kept in a fast shared cache so any instance can route a message to the right connection.
- → Long Polling: Long polling is the common fallback transport for clients/networks that can't complete a WebSocket upgrade handshake.
- → Server-Sent Events (SSE): SSE is a lighter-weight alternative when the app only needs server-to-client push, not full bidirectional messaging.