WebSocket backpressure: when clients can''''t keep up

Your WebSocket broadcast server handles 10,000 clients fine during testing. In production, 100 clients on slow mobile connections start lagging behind. The server’s memory climbs. GC pauses lengthen. Then the OOM killer fires and takes down the entire service. This is the canonical WebSocket failure mode — and it has nothing to do with the protocol.

The TCP receive window, from the application’s view

TCP gives every socket a receive window — the number of bytes the receiver can accept before the sender must pause. As the application on the receiving end reads bytes, the window opens; as it falls behind, the window shrinks to zero and the sender stalls.

From the server’s perspective:

1. Server calls send(socket, message).
2. The kernel copies the message to the socket’s send buffer.
3. TCP transmits from the send buffer, subject to the client’s advertised receive window.
4. If the client’s window is zero (its read buffer is full), TCP stops transmitting.
5. The kernel’s send() call blocks if the send buffer is full, or returns EAGAIN in non-blocking mode.

For a broadcast server with thousands of clients, this creates a critical asymmetry: fast clients drain their buffers in milliseconds; slow clients leave the server’s bytes sitting in kernel send buffers, and when those buffers fill, the server is stuck.

The application-level send queue

Production WebSocket servers never block on send(). Instead, they maintain an application-level send queue per connection. When the server broadcasts a message, it enqueues it for each connection and returns immediately. A background writer drains each queue into the kernel as fast as the client’s TCP window allows.

This solves the blocking problem — but creates a new one: queue unbounded growth.

Consider this scenario:

• Server broadcasts a 100 KB message every 10 ms.
• 100 of 10,000 clients are slow — database queries are blocking their read thread.
• Each slow client’s queue grows by: 100 messages/second × 100 KB = 10 MB/second.
• After 10 seconds: 100 slow clients × 10 MB × 10 s = 10 GB of RAM consumed by queues.
• OOM killer fires.

The high-water mark pattern

The solution is a high-water mark: a per-connection queue limit that triggers eviction or backpressure.

When a connection’s send queue exceeds the high-water mark (e.g., 100 messages or 10 MB), the server chooses:

Option A — evict the connection. Forcibly close the slow client with status code 1013 (“try again later”). The client reconnects when its network clears. Other clients are unaffected. This is the standard choice for broadcast services.

Option B — drop messages. For idempotent data (stock prices, game state snapshots) where the latest value supersedes older ones, drop old messages and only keep the newest N entries per connection. The slow client gets the current state on reconnect rather than stale history.

Option C — pause the producer. For peer-to-peer streams (video conference, file transfer), signal the sending application to pause until the queue drains below the low-water mark. This is full backpressure propagation.

The proxy idle timeout failure mode

There is a second common failure mode: a proxy between client and server has a 60-second idle timeout. If no bytes cross the TCP connection in 60 seconds, the proxy closes the TCP connection — without sending a WebSocket close frame.

Both client and server are unaware until the server tries to send the next message: send() returns EPIPE or ECONNRESET. The client sees a close event with code 1006 (abnormal closure). The connection is dead.

Fix: the server sends a ping frame every 25–30 seconds. The ping resets the proxy’s idle timer. The client must reply with a pong within a reasonable window (the server can evict clients that don’t pong within 10 seconds as a stale connection cleanup).

2026-05-15T14:32:00Z broadcast_service[5234]:
active_connections: 50234
total_queued_bytes: 8589934592  (8 GB)
slow_client_count: 127
p95_queue_depth: 156 messages
p99_queue_depth: 341 messages
broadcast_latency_p99: 18432ms
memory_usage: 15.2 GB / 16 GB heap
gc_pause_time: 1247ms

2026-05-15T14:32:15Z broadcast_service[5234]:
active_connections: 49891  (-343 in 15s)
total_queued_bytes: 10737418240  (10 GB)
slow_client_count: 412
p95_queue_depth: 287 messages
p99_queue_depth: 502 messages
broadcast_latency_p99: 32568ms
memory_usage: 15.8 GB / 16 GB heap
gc_pause_time: 2100ms

2026-05-15T14:32:30Z broadcast_service[5234]: OOM killer invoked; process killed