Back to the Catalog
websockets
real-time
system-design
networking

Scaling WebSockets: Sticky Sessions, Fan-Out & Backpressure

11 questions

Running real-time WebSockets across a fleet: why connections need sticky sessions, how a pub/sub backplane fans messages across nodes, tracking presence, per-connection backpressure with bufferedAmount, reconnect storms, and the file-descriptor ceiling. The fan-out math is verified in Node.

Start

Questions

  1. Not answered. You put 3 WebSocket servers behind a per-request round-robin load balancer, and connections keep breaking. Why — and what's the fix?
  2. Not answered. Clients are spread across 3 WebSocket servers. A message from a user on server A must reach a recipient connected to server B. What architecture solves this?
  3. Not answered. Which read-only WebSocket property reports how many bytes you've queued with send() that haven't yet gone out to the network?
  4. Not answered. Which statements about tracking presence (who's online) across a WebSocket fleet are correct?
  5. Not answered. You broadcast a fast stream, and one client is on a slow network. If you ignore its outbound buffer, what happens on the server?
  6. Not answered. A WebSocket server holding 50,000 connections crashes, and every client tries to reconnect at once. What's the risk and the mitigation?
  7. Not answered. Why is a stateless HTTP API generally easier to scale horizontally than a WebSocket service?
  8. Not answered. You broadcast 5 messages per second to 100,000 connected clients. How many individual sends per second is that across the fleet?
  9. Not answered. Which are valid ways to keep a client's WebSocket traffic pinned to a single backend?
  10. Not answered. What OS-level resource does each open WebSocket consume on the server, and why does it cap one machine's connection count?
  11. Not answered. For a live data feed (say, cursor positions in a collaborative app), how should you handle a client whose send buffer is backing up?