Backpressure in Node.js streams

What's really being asked

This evaluates deep stream knowledge and whether you can prevent unbounded memory growth when one side of a data flow is slower than the other, a real concern when serving large files to slow clients.

The full answer

Backpressure is the feedback signal that prevents a fast readable stream from overwhelming a slower writable one. Each writable has an internal buffer bounded by its highWaterMark. When you write data faster than it can be flushed, the write call returns false, indicating the buffer is full. The producer should then stop until the writable emits a drain event signaling room is available. Without this, data piles up in memory until the process runs out. The pipe method handles all of this automatically: it pauses the source when the destination returns false and resumes on drain, keeping memory bounded. stream.pipeline does everything pipe does and additionally propagates errors through a single callback or promise and guarantees all streams are properly destroyed if any link fails, avoiding leaked file descriptors. This is why pipeline is preferred in modern code.

The mistakes people make

Thinking backpressure is about network bandwidth alone rather than buffer-level flow control. Writing in a loop while ignoring write's false return, which defeats backpressure. Believing pipe handles error cleanup, which it does not, leading to leaks.

What usually comes next

What is highWaterMark and how does tuning it affect throughput. Why does pipe leave streams open on error. How does async iteration over a stream interact with backpressure.

A concrete example

Serving a 2GB file to a client on a slow connection: fs.createReadStream(file).pipe(res) pauses disk reads whenever the socket's send buffer fills and resumes on drain, so memory stays near the highWaterMark. A naive readFile-then-write approach would buffer the whole 2GB. Using pipeline(readStream, res, err => {}) adds clean error handling if the client disconnects mid-transfer.