streams-backpressureAnswer last reviewed July 2026

Say the writable side just can't keep up with the readable that's feeding it. Walk me through what happens, step by step.

A strong answer walks the backpressure protocol step by step, from the write() return through buffered bytes to drain, and on down into TCP flow control

What an AI-prepared candidate might say

So when the writable side is slower, its internal buffer starts filling up. Every write() call adds the chunk to that buffer, and once the buffered amount hits the highWaterMark, write() returns false, which is basically telling the producer to stop for a bit. Then the producer is supposed to wait for the 'drain' event, that fires when the buffer has emptied out, and then it can start writing again. If you connect things with pipe() this is all handled for you, it pauses the readable when the destination returns false and resumes it on 'drain'. And that's backpressure, really. The consumer's speed propagates back to the producer so data doesn't pile up in memory. If you're writing manually and you ignore the false return, Node just keeps buffering and memory grows, so you kind of have to respect that false.

Senior
Locked

The whole protocol walked in order, buffered bytes against highWaterMark, the advisory false, drain firing at empty, and how a paused socket closes the TCP window on the far end.

Unlock the depth
Staff
Locked

What happens in a fanout service when someone ignores false, the writableLength gauges that catch it early, and slow-consumer policies you can actually defend.

Unlock the depth
Follow-up chain
Say the writable side just can't keep up with the readable that's feeding it. Walk me through what happens, step by step. | NodeBook