A fast producer, a slow consumer, and the one signal that flows backward to keep memory bounded.

State the seed precisely, because everything grows from it. A producer emits data at one rate; a consumer absorbs it at another; the total volume is large or unbounded (a 10 GB file, an infinite socket). You cannot buffer it all — "read everything, then process" detonates your heap. So you stream: process in chunks with a bounded working set, and you need a way for the slow side to throttle the fast side. That throttle is backpressure, and it's the only idea in this whole document — seen at six heights.

Drag the slider below to feel why "read it all" is a non-starter. The same job — move a file to a slow sink — costs either a bounded few kilobytes of buffer or the entire file resident in RAM, depending only on whether you stream.

The vocabulary you'll reuse at every layer. Tap each to open the detail — and notice that push vs pull is the axis that quietly decides whether backpressure is automatic or something you must build.

One axis explains most of the design differences you'll meet. In a push model the producer calls the consumer the instant data exists — fast, but if the consumer is slow the surplus has to go somewhere, so push needs an explicit buffer and an explicit "stop" signal. In a pull model the consumer requests the next chunk only when it's ready for one — so the producer literally cannot run ahead, and backpressure is the default, not a feature. Toggle the two modes below and watch the queue. Same producer, same slow consumer; the only change is who's in charge of timing.

"First principles" bottoms out here. Every stream reduces to two syscalls — read(2) and write(2) — operating on a file descriptor. Between them, data sits in kernel buffers: the page cache for files, the socket send/receive buffers for sockets, the fixed pipe buffer for pipes. And the kernel already has backpressure: on a non-blocking fd whose send buffer is full, write doesn't block — it returns EAGAIN. That refusal is the real backpressure signal. Node's writable.write() returning false is nothing more than the userspace echo of EAGAIN.

The diagram traces the whole chain for a TCP write: your write → the socket send buffer → the TCP sliding window → the peer's receive buffer → the peer app's read. A full receive window propagates back to a full send buffer propagates back to your write returning EAGAIN. Inspect it, then run the strace below to watch a real read/write/EAGAIN/epoll_wait interleaving.

Each clause of the chain is a card. The story climbs from a single fd up to io_uring; the punchline is always that the kernel already solved this, and Node is plumbing the signal up to JavaScript.

Build the cleanest possible stream out of language features alone, so that later you can see exactly what Node's machinery is rebuilding. An async generator produces values lazily: it runs to a yield, hands one value out, and suspends. A for await…of loop pulls the next value only when the body finishes. So if the body is slow, the generator simply waits at its yield — the consumer literally cannot pull the next chunk until it finishes the current one. Backpressure is automatic, and you wrote zero plumbing. Run it and watch the generator sit suspended while the slow body works.

An EventEmitter is a Map<eventName, Function[]> where emit is a synchronous for-loop over the array. Push-based I/O maps onto it naturally: a chunk arrives, emit('data', chunk) shoves it at every listener, synchronously, right now. That immediacy is the problem — emit has no buffer and no backpressure. If the listener is slow, emit doesn't care; it already moved on. Streams are built on this push substrate, and the buffering and flow control they add is exactly the thing the bare emitter lacks. Here are the stream-relevant events you'll meet properly in the next phase.

Five types: Readable (source), Writable (sink), Duplex (both, independent), Transform (both, coupled — gzip, crypto), and PassThrough (a Transform that does nothing). Each holds an internal buffer governed by highWaterMark — which is a threshold, not a hard cap: cross it and write() still accepts your chunk and buffers it, but returns false to say "I'm over the line, please pause." When the buffer drains below the mark it emits 'drain'. That call-and-response is the drain dance, and it is the kernel's EAGAIN/epoll-writable cycle from Phase 3, rebuilt in userspace. Step through it.

Now make it live. Drag highWaterMark and consumer speed; the loop writes as fast as it can while respecting the false return. A correct loop never lets the buffer run away — that bounded ceiling is backpressure working.

pipe() vs pipeline()

pipe() wires a source to a destination and manages the drain dance for you — pause the source when the dest returns false, resume on 'drain'. Its flaw: on error it does not tear down the rest of the chain, leaking sockets and file descriptors and leaving half-open streams. pipeline() (and stream/promises' promise form) fixes exactly that — it propagates errors and destroys every stream in the chain, in order. The rule in real code: never bare pipe() across more than two stages; reach for pipeline().

The WHATWG standard (now built into Node, and what fetch() bodies are) keeps the three roles — ReadableStream, WritableStream, TransformStream — but fixes classic streams' biggest wart: backpressure here is a number you can read. A controller exposes desiredSize = highWaterMark − queued. When it's positive the stream wants more and calls your pull(); when it goes to zero or negative, you stop enqueuing. No mode-switching, no implicit _read re-invocation guesswork — just a gauge. Drag the consumer speed and watch desiredSize swing, and pull() fire only when there's room.

The real test: file → gzip transform → socket → network. Each boundary is a place backpressure can stall, and a correct pipeline propagates one slow stage all the way back to a paused file read. In Node, req is a Readable and res is a Writable; an HTTP response streaming a gzipped file is exactly this chain. Watch the signal originate at a congested network and travel left, stage by stage, until the disk read itself pauses — and notice that no stage holds more than its own buffer.

Pull, push-with-rebuilt-backpressure, push-with-explicit-backpressure: async iterators, classic Node streams, and Web Streams are not three unrelated APIs but three answers to the same question. Other ecosystems answer it too — some elegantly, one as a cautionary tale.

The kernel expresses it as EAGAIN. Async iterators express it by simply not calling next() yet. Classic Node streams express it as write() returning false and an eventual 'drain'. Web Streams express it as a desiredSize that drops to zero. Reactive Streams express it as request(n). They are dialects of one sentence. Learn to hear the sentence under the dialect and streams stop being API trivia and become — finally — obvious.