Backpressure in WebSockets

Analogy categoryAnalogies

What Backpressure Means for 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.

🏏

Cricket analogy: It's like a stadium's giant screen operator feeding replay clips into a queue faster than the video switcher can broadcast them; the clips don't vanish, they pile up in a buffer, and if the operator never checks the queue length, it eventually overflows the system's storage.

Detecting Backpressure

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.

🏏

Cricket analogy: It's like a ground announcer checking how many replay requests are still queued before adding another one to the list; if the queue is already backed up past a threshold, they hold off on adding more until the operator has caught up, rather than piling on regardless.

javascript

// Node.js 'ws' server: simple flow control using bufferedAmount
const BUFFER_THRESHOLD = 1 * 1024 * 1024; // 1MB

function sendIfNotBackedUp(ws, message) {
  if (ws.bufferedAmount > BUFFER_THRESHOLD) {
    // Client can't keep up; drop or coalesce instead of queuing more
    console.warn(`Slow client detected, dropping message (bufferedAmount=${ws.bufferedAmount})`);
    return false;
  }

  ws.send(JSON.stringify(message), (err) => {
    if (err) console.error('Send failed:', err);
  });
  return true;
}

// Periodically check for chronically slow clients and disconnect them
setInterval(() => {
  wss.clients.forEach((ws) => {
    if (ws.bufferedAmount > BUFFER_THRESHOLD * 10) {
      ws.terminate(); // buffer never drains; cut losses
    }
  });
}, 5000);

Strategies to Handle It

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.

🏏

Cricket analogy: It's like a ball-tracking overlay system that only needs to show the current position of the ball, not every historical position, so under load it happily discards stale tracking frames and just displays the latest one, unlike a wicket-fall alert which must never be dropped.

An unbounded per-client send queue is a classic memory-exhaustion vector, and it's also an easy denial-of-service surface: a malicious or simply misconfigured client can open a connection, stop reading entirely, and force the server to buffer everything sent to it indefinitely. Always pair backpressure detection with a hard cap: once bufferedAmount exceeds a maximum you're willing to hold (not just a soft throttling threshold), terminate the connection outright rather than letting it consume memory indefinitely.

Server-Side Flow Control

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.

🏏

Cricket analogy: It's like a stadium PA system with a hard rule that no single commentary queue can exceed thirty seconds of backlog, enforced consistently across every announcer's microphone, so no single overenthusiastic commentator can flood the system regardless of which booth they're broadcasting from.

Coalescing is a cheap, effective middle ground for latest-value data: instead of sending every update immediately, buffer updates in a single-slot variable (overwriting the previous one) and flush it on a fixed interval, e.g., every 100ms. This bounds both the send rate and the memory used to at most one pending message per client, regardless of how fast the upstream producer generates updates.

Backpressure occurs when a producer sends faster than a consumer (slow client, weak network) can drain the connection.
bufferedAmount is the key metric for detecting a WebSocket send queue that's growing unboundedly.
The send() callback in Node's ws library fires once data is flushed to the OS buffer, enabling simple flow control.
Latest-value data (cursor positions, prices) can be safely dropped/coalesced; discrete events (chat, orders) must be throttled, not dropped.
Unbounded per-client queues are both a memory-exhaustion risk and a denial-of-service surface; always enforce a hard disconnect cap.
TCP's own flow control eventually blocks writes to a slow client, but application-level handling lets you choose the outcome intentionally.
Coalescing (buffer-and-flush-on-interval) bounds both send rate and memory for high-frequency latest-value updates.