Where 'backpressure' actually lives

"The client can't keep up" sounds abstract until you trace where the bytes actually sit. There are exactly two places, and both are on YOUR machine:

1. The kernel's socket send buffer. send()/write() doesn't transmit — it copies into a per-socket kernel buffer (typically 64 KB–4 MB) and returns. TCP drains it at whatever rate the receiver acknowledges. When the receiver stalls, this buffer fills; the next write blocks (blocking sockets) or returns EWOULDBLOCK (non-blocking).
2. Your userspace queue. The moment the kernel buffer is full, every frame you still want to send has to wait somewhere in your process — an explicit outgoing queue, a promise chain, or the browser's bufferedAmount. This queue has no built-in limit. It grows until you stop it or the process dies.

Backpressure is the discipline of noticing #1 and bounding #2. The number to watch is bytes buffered per connection — the exercise's STATE command (buffered=<b> max=<m>) is exactly the gauge real servers expose. A WebSocket server without that number is a memory leak with a network protocol attached.