What Happens When the Receiver Is Slow

Follow the bytes. The sender writes; the kernel transmits; the receiver’s kernel appends to the socket receive buffer. The receiving application reads slowly, so the buffer fills. The receiver’s kernel advertises a shrinking window with every ACK, and when the buffer is full it advertises zero (see Flow Control: The Receive Window). The sender’s TCP stops transmitting — not because of the network, which is fine, but because the receiver said stop. Now the sender’s socket send buffer fills, because the application keeps writing and nothing leaves. When it is full, write() can no longer copy, and the sender’s application is stopped by the receiver’s application, four queues and one network away.

While the window is zero the sender sends zero-window probes — one byte, with exponential backoff — so that it learns when the receiver frees space even if the window update is lost. Linux gives up and resets the connection only if the probes go unanswered entirely (a dead peer), not if the peer simply keeps answering with a zero window; a slow receiver can hold a sender indefinitely. ss -ti shows the state on both ends: Recv-Q at its buffer limit on the receiver, Send-Q at its limit on the sender, and a window of 0 in the sender’s rcv_space/snd_wnd. See The Buffer Chain for the chain.

This is the correct behaviour. Flow control exists so that a fast producer cannot overwhelm a slow consumer; the alternative is dropping data or growing memory without bound. The interesting question is only how the sending *application* experiences the stop.

A blocking socket is the simplest: write() sleeps until there is room, and the calling thread is stalled for as long as the receiver is slow — which is fine in a thread-per-connection server (only that thread waits) and fatal in an event loop (everyone waits). A non-blocking socket returns a short count or EAGAIN; the caller must keep the unwritten remainder and wait for a writable event from epoll/kqueue before trying again. Every event-driven framework wraps this pattern; hand-rolled code gets it wrong by dropping the remainder or spinning.

Runtimes expose it in their own vocabulary. In Node.js, writable.write(chunk) always accepts the chunk (into the stream’s own buffer) and returns false when the buffered amount exceeds highWaterMark (16 KiB by default for net.Socket); the correct response is to stop writing until the 'drain' event. pipe() and stream.pipeline() do this for you. In Python asyncio, writer.write(data) buffers in the transport and await writer.drain() suspends the coroutine until the buffer is below the high-water mark; transport.pause_reading() is the same signal in the other direction. In Go, conn.Write blocks the goroutine (not the OS thread) until the data is copied into the kernel. In Java NIO, SocketChannel.write in non-blocking mode returns fewer bytes than offered, and you register OP_WRITE. Same mechanism, five spellings.

The rule shared by all of them: the signal that the consumer is slow must reach the producer, and the producer must stop generating. A write() that never blocks and never says no is not solving backpressure; it is hiding it in a buffer.

The kernel’s buffers are bounded and push back. The failure appears when an application decides that pushing back is inconvenient and buffers in user space instead: a Node service that ignores the false from write(), an asyncio service that never calls drain(), a broker client with an unbounded outgoing queue, a proxy that reads the whole upstream response "to be safe" before writing any of it. Each slow consumer now costs the producer memory at the rate of the speed difference, indefinitely. The process grows, GC pauses lengthen (making everything slower, so buffers grow faster), and it dies of OOM or is killed by the OOM killer (see Memory Pressure, Swap and the OOM Killer). The kernel did its job; the application undid it.

The same shape exists at every scale: an unbounded Queue in front of a thread pool (The Thread Pool Server), a message broker that accepts publishes faster than consumers drain and grows its disk until it fails, an event-sourcing pipeline whose slowest stage silently sets the memory of every stage before it. The Software Architecture answer — bounded queues, backpressure-aware streams, drop or reject policies — is the same as the kernel’s, and it must be applied at each hop where someone might otherwise buffer.

The decision when the consumer is slow is always one of three: stop the producer (backpressure, the default and usually right), drop (acceptable for real-time data where late is useless: metrics, video frames), or buffer with a bound and then do one of the first two. Unbounded buffering is not a fourth option; it is dropping, later, all at once, with a core dump.