streams-backpressureAnswer last reviewed July 2026

Readable streams have this flowing mode and paused mode thing. What's actually different between the two, and what flips a stream from one to the other?

A strong answer knows the readable mode state machine, which APIs flip it, what readableFlowing's three states mean, and where data quietly vanishes

What an AI-prepared candidate might say

So there are two consumption modes on a readable. In flowing mode the stream pushes chunks at your 'data' listeners as fast as they come in. In paused mode you pull explicitly with read(), usually inside a 'readable' handler. Streams start out paused, I'm pretty sure. Then attaching a 'data' listener, calling resume(), or piping to a destination flips it to flowing, and pause() flips it back. Flowing is just the plain push style, and paused gives you control over when and how much you consume. Honestly modern code doesn't really manage this by hand, pipe, pipeline, and for await handle the modes internally. But the modes explain some classic surprises, like a stream that just sits there doing nothing until a 'data' listener shows up and then suddenly fires chunks all at once.

Senior
Locked

The three readableFlowing states, exactly which calls move you between them, and the read(n) contract that makes byte-exact protocol parsing clean.

Unlock the depth
Staff
Locked

The mixed-mode bug class that shows up in real codebases, the resume-without-listener trap that loses data silently, and why modern code hides both modes behind pipeline and iterators.

Unlock the depth
Follow-up chain
Readable streams have this flowing mode and paused mode thing. What's actually different between the two, and what flips a stream from one to the other? | NodeBook