Bytes arrive whether or not you are ready.

What a Readable actually is

Four things live on it, and they answer four different questions. The state answers what do I hold right now. The methods answer how is the queue moved. The events answer how do I announce a change. The protocols answer what standard shapes can consume me.

Three surfaces onto one queue

The four groups above collapse into three ways of getting bytes out. They are not three streams. They are three doors onto the same queue, and taking a chunk through one door means the other doors will never see it.

The prototype chain, and why req.read() resolves

When Node hands you a request object, the stream behaviour is not copied onto it. It is found by walking a chain. This matters because it explains precisely which properties are HTTP concerns and which are stream concerns.

Both facts follow from the same walk. Stream behaviour is inherited, so it lives several links up. HTTP identity is an own property of the instance, so the walk stops immediately and never reaches the stream layer at all.

From kernel to JavaScript

Bytes do not arrive in your callback. They arrive in a kernel buffer attached to a file descriptor, and they sit there until something on Node's side asks for them. Each layer below hands the bytes upward in a different representation.

Two properties of this stack are worth pinning down, because most confusion about Node streams comes from getting either one wrong.

• The bytes are copied once, out of the kernel and into a slab. From there upward the same memory is re-described, not re-copied.
• The only channel that runs downward is the return value of push(). There is no other way for your consumer to tell the socket anything.

The polling loop, and what idle actually means

Node does not spin. When there is nothing to do, the thread running the event loop is parked inside a blocking syscall that the OS wakes when a watched descriptor becomes ready — epoll_wait on Linux, kevent on the BSDs and macOS, a completion port on Windows.

Where an arriving chunk is allocated

Every read from a socket needs somewhere to put the bytes. Allocating a fresh region per packet would produce enormous garbage-collector pressure at high connection counts, so Node allocates a block up front and hands out slices of it.

_readableState — the record every decision reads

Node's real implementation carries around thirty fields. These are the ones that participate in data flow; the rest are bookkeeping for destruction, encoding and object mode.

readable._readableState = {
  buffer: [],            // queue of chunks, oldest first
  length: 0,             // total bytes currently queued
  highWaterMark: 16384,  // the threshold that flips the return value

  flowing: null,         // null | false | true
  reading: false,        // a fill is already in flight
  ended: false,          // producer signalled end of data
  endEmitted: false,     // the 'end' event has already fired
  destroyed: false,
};

push(), line by line

This is the producer's only entry point. Read it as four separate decisions rather than one function, because each line answers a question asked by a different part of the system.

Readable.prototype.push = function (chunk) {
  const state = this._readableState;

  // 1 — normalise. Strings become bytes using the stream's encoding.
  if (chunk !== null && !Buffer.isBuffer(chunk)) {
    chunk = Buffer.from(chunk);
  }

  // 2 — null is the end-of-data sentinel, not an empty chunk.
  if (chunk === null) {
    state.ended = true;
    this.emit('readable');
    return false;
  }

  // 3 — queue it, then decide whether anyone is listening right now.
  state.buffer.push(chunk);
  state.length += chunk.length;

  if (state.flowing === true) {
    this.emit('data', chunk);   // push channel — hand it straight over
  } else {
    this.emit('readable');      // pull channel — announce, do not hand over
  }

  // 4 — the only signal that travels back to the producer.
  return state.length < state.highWaterMark;
};

Line 3 is the one that surprises people. The chunk is queued before the channel decision, and in the push case it is then handed straight to the listener in the same call stack. There is no scheduling step in between — your 'data' handler runs synchronously inside the libuv callback that produced the bytes.

The flowing flag has three states, not two

Almost every stream bug that looks like "my data vanished" is this flag being in a state the code did not expect. null is not a synonym for false: a stream that has never been consumed behaves differently from one that was explicitly paused.

Two channels over one queue

req.on('data', (chunk) => {
  process(chunk);
});

for await (const chunk of req) {
  await process(chunk);
}

read(), line by line

The mirror image of push(). Where push() ends by deciding whether to say stop, read() ends by deciding whether to say go again.

Readable.prototype.read = function (size) {
  const state = this._readableState;

  // 1 — is there anything queued right now? This check is synchronous.
  if (state.length === 0) {
    if (!state.reading && !state.ended) {
      state.reading = true;
      this._read(size);   // ask the producer to fill — returns immediately
    }
    return null;          // null means "not yet", not "finished"
  }

  // 2 — take the oldest chunk out of the queue.
  const chunk = state.buffer.shift();
  state.length -= chunk.length;

  // 3 — draining may have taken us back under the threshold.
  if (state.length < state.highWaterMark && !state.reading && !state.ended) {
    state.reading = true;
    this._read(size);     // this is what restarts the socket
  }

  return chunk;
};

The async iterator, and where the promise waits

The pull channel is built out of the two primitives above plus one promise. Nothing in it is special-cased by the engine — it is ordinary JavaScript sitting on read() and the 'readable' event.

Readable.prototype[Symbol.asyncIterator] = async function* () {
  while (true) {
    const chunk = this.read();

    if (chunk !== null) {
      yield chunk;                       // hand it to the loop body
      continue;                          // and only ask again once the body returns
    }

    if (this._readableState.ended) return;   // queue empty and no more coming

    // queue empty but not ended — suspend until the producer announces a chunk
    await new Promise((resolve) => this.once('readable', resolve));
  }
};

The important line is the yield. A generator suspends at yield and does not resume until the consumer asks for another value, so the read() call for chunk two literally cannot happen until the loop body for chunk one has returned. That single fact is what makes the pull channel safe by construction.

Backpressure is one boolean, propagated

Both halves have to be present. A producer that ignores the return value has no backpressure. A consumer that never drains the queue has no backpressure either, because _read() is never called and the loop never closes.

Where the data goes while the socket is paused

It does not disappear and it is not dropped. It accumulates in the kernel receive buffer, and when that fills, TCP's own flow control advertises a smaller receive window to the sender, which slows the machine at the other end of the connection. Backpressure inside your process and backpressure on the wire are the same mechanism observed at two scales.

The same eight chunks, three ways

One producer delivering eight 8 KB chunks into a stream whose threshold is 16 KB. The only thing that changes between the three traces is the consumer. Step through and watch the queue, the return value and the socket.

Push against pull

The one-sentence version