Streaming and backpressure: when the client reads slower than you write

A reporting service streams a 400 MB CSV export. It works in tests. In production it OOMs and restarts every afternoon. The export code is fine — it reads rows and calls res.write() in a tight loop. The bug is that one customer downloads over a phone tethered at 200 KB/s, and the server generates rows far faster than that phone can read them. The unread bytes pile up in the process heap until the kernel kills it.

Buffer vs stream

There are two ways to send a body. Buffer: build the whole response in memory, set Content-Length, send it. Simple, but a 400 MB export means 400 MB resident per concurrent download. Stream: produce the body in pieces and write each piece as it is ready, using Transfer-Encoding: chunked so the total size need not be known up front. Streaming keeps memory flat — if you respect backpressure.

Backpressure: the write that says “stop”

Every writable stream has a buffer with a threshold called the high-water mark (Node’s default is 16 KB for byte streams, 64 KB for filesystem streams). The mechanism:

• res.write(chunk) returns true while the internal buffer is below the high-water mark — keep writing.
• It returns false when the buffer is full — stop writing and wait for the 'drain' event before continuing.

write() returning false does not mean the write failed. It means the consumer is behind and the buffer is full. If you ignore the false and keep writing anyway, the data does not vanish — it accumulates in the stream’s internal buffer in your process heap. That is the OOM. The fix is to honor the signal: pause production until 'drain'. pipe() and pipeline() do this for you automatically, which is why pipeline(source, res) is the safe default and a hand-rolled while loop of write() is the classic footgun.

Why the buffer fills: it is turtles down to TCP

Backpressure is not a Node invention; it is the application-level surface of a chain of flow-control windows. The client’s TCP receive window advertises how much it can accept. When the client app reads slowly, its receive buffer fills, it shrinks the advertised window, and the server’s kernel send buffer stops draining. The userland writable stream then stops draining, write() returns false, and — if you listen — your code stops producing. Each layer pushes back on the one above it. Ignoring backpressure means decoupling your production rate from this entire chain, so the gap accumulates in the one place with no flow control: your heap.

The slow-consumer attack

The same mechanism is a denial-of-service vector. Slowloris and slow-read attacks deliberately read responses one byte at a time to hold connections open and keep server-side buffers occupied. A server that buffers per connection and ignores backpressure can be exhausted by a handful of slow clients — no volume needed. Defenses are the same as the correctness fixes plus limits: honor backpressure, cap per-connection buffering, and set write/idle timeouts so a stalled drain is abandoned rather than held forever (the subject of the next lesson).