Backpressure in WebSockets

Backpressure is what happens when a producer sends data faster than a consumer can process or receive it. On a WebSocket, this shows up when the server calls send() repeatedly but the underlying TCP connection, whether because of a slow client CPU, a congested mobile network, or a client tab that's backgrounded and throttled by the browser, can't drain the socket's send buffer fast enough. The bytes don't vanish; they queue up in an internal buffer, and if the producer keeps writing without checking that buffer's size, it grows unboundedly. In Node.js, the ws library and the browser's native WebSocket API both expose this queue length via a property called bufferedAmount, which is the single most important number to watch when diagnosing a WebSocket server that's slowly consuming more and more memory under load from a handful of slow clients.

The practical fix starts with actually checking bufferedAmount before writing more data: if it exceeds a chosen threshold (say, 1MB), the server should pause sending new messages to that specific client until the buffer drains below the threshold again, rather than blindly continuing to enqueue more data. In Node.js specifically, the ws library's send() method also accepts a callback that fires once the data has actually been flushed to the OS socket buffer (not necessarily received by the client, but at least handed off), which can be used to implement simple flow control by not issuing the next send until the previous callback has fired. Polling bufferedAmount on a timer (checking every 100-500ms for connections identified as consistently slow) is a common lightweight pattern that avoids adding per-message overhead while still catching runaway buffers before they become a memory problem.

Once you detect a slow consumer, there are a few standard strategies, and the right one depends entirely on the message semantics. For state that only needs the latest value, like a live cursor position or a stock price, you can safely drop or overwrite queued messages, keeping only the most recent one, since an old cursor position is worthless once a newer one exists; this is sometimes called 'latest-value' or 'conflation' semantics. For messages that represent discrete events, like chat messages or order confirmations, dropping isn't acceptable, so instead you throttle the producer (send less frequently, batch multiple small updates into one larger message) or apply true backpressure by pausing the upstream data source entirely until the client catches up. A third option, useful for streams like live video or telemetry, is to reduce fidelity under pressure, sending a lower-resolution or sampled version of the data rather than the full stream, so the client gets something useful instead of nothing.

Beyond per-message checks, well-designed WebSocket servers set explicit per-connection queue limits as a configuration parameter, not an afterthought, and enforce them consistently across every message-sending code path in the application, since a single unguarded send() call anywhere in a large codebase can reintroduce the exact memory problem the rest of the system carefully avoids. It's also worth remembering that TCP itself has its own flow control (the receive window), which means a sufficiently slow client will eventually cause the underlying socket's write() calls to block or return asynchronously even before bufferedAmount grows very large; application-level backpressure handling is what lets you make an intentional choice (drop, throttle, or disconnect) rather than letting the OS-level TCP behavior alone determine what happens, which by default is just an ever-growing user-space queue in most WebSocket library implementations.