A yard system pushes position updates over a WebSocket faster than the cabin console consumes them - what in the protocol tells the sender to slow down?

## The protocol's own answer is: there is no signal WebSocket gives you framing, a liveness probe, a negotiated name and a close handshake. It does not give you flow control. There is no credit scheme, no receive window at the message layer, no acknowledgement, and no message a receiver can send that means *send less*. A sender is never told that a message was delivered, let alone consumed, so it cannot pace itself on anything the protocol reports. This is less an oversight than a division of labour - and it is the most consequential absence in the protocol, because it turns a transport question into an application design. ## Where the backpressure actually lives A WebSocket runs over TCP, and TCP does have flow control. The chain, in order: 1. The receiving **application** stops reading from its socket, because it is busy rendering, parsing, or writing to something slow. 2. Its kernel **receive buffer** fills, because nothing is draining it. 3. Its TCP stack **advertises a smaller window**, eventually zero, so the peer's stack stops putting bytes on the wire. 4. The sending side's kernel **send buffer** fills. 5. Only now does the sending **application** feel anything: its writes stop completing. The important property of that chain is how late and how indirectly step 5 arrives. Megabytes of buffering sit between the receiver's decision to stop reading and the sender's first hint that anything is wrong, and by then the data at the head of the queue is already old. ## What the sender actually observes - **An outbound queue that grows.** The messages the application handed over are held somewhere - in its own process, in the kernel - and that memory is the sender's. - **No error.** Nothing fails, nothing reports a problem. Handing a message over succeeds whether or not it will ever be delivered. - **A healthy-looking connection.** Liveness probes are small and are answered promptly, because answering one does not require the receiver to consume the backlog. A connection can look perfectly alive while being hours behind. - **Staleness rather than loss.** The receiver eventually gets every message, including the position update from four minutes ago that it will now render as current. That last point is the one that surprises people: the failure of an unthrottled feed is usually not a dropped message, it is a correct message delivered far too late, plus memory growth on the side that never noticed. ## What the protocol does not decide for you Because the wire offers no signal, every option lives above it: what a sender should do when it produces faster than a consumer drains is an application policy with real tradeoffs - one this leaf deliberately hands on rather than answers. What matters at the protocol level is knowing **why** the decision exists: it exists because there is no message the receiver can send to make it go away. The corollary is that the decision must be made explicitly, at the point where messages are produced. A system that produces at whatever rate its source runs at, and hands every message to the socket, has chosen a policy - unbounded buffering and unbounded staleness - it simply has not chosen it on purpose. ## The version wrinkle worth knowing A WebSocket opened over HTTP/1.1 rides a TCP connection directly, and the chain above is the whole story. A WebSocket bootstrapped over HTTP/2 or HTTP/3 rides a **stream**, and streams do have their own transport flow-control windows. That changes the machinery underneath - a stalled socket can now stall on the stream's window before the connection's - but it does not change the answer: those windows are transport-level and are not surfaced to the WebSocket application either. There is still no message the receiving application can send to ask for less. ## How to talk about it in an interview The strong answer has three moves, in this order: state the absence precisely (no application-visible flow-control signal in the protocol), name the backpressure that does exist and where it lives (TCP, several buffers away), and describe what the sender actually sees (a queue, no error, a healthy-looking connection, stale data). Then say the policy is an application decision. A candidate who says only *use backpressure* has not shown they know the protocol supplies none.