streams-backpressureAnswer last reviewed July 2026

Say you have to proxy a big HTTP response through your service without buffering the whole thing. How do you do it, and what actually breaks if you get it wrong?

A strong answer treats the HTTP request and response objects as the streams they are, and can build a proxy whose memory never tracks body size

What an AI-prepared candidate might say

So in Node the incoming request is a readable stream and the response you're sending is a writable, and a proxy is basically just connecting the two. You make the upstream request, then pipe the upstream response into your server response, and you have to write the status code and headers before the body starts. With stream.pipeline(upstreamRes, res) the data flows through in chunks and memory stays flat no matter how big the body is. If your memory scales with response size, you're buffering somewhere, collecting the whole upstream body before sending it on, like with await response.json() or concatenating chunks by hand or something. Backpressure comes along for free, if the client is slow the pipe slows the upstream read down too. And you need error handling for either side dying mid-transfer, which pipeline covers by cleaning up both streams.

Senior
Locked

The anatomy of req and res as streams, getting headers out before the body flows, and the end-to-end backpressure that lets a slow phone throttle your upstream fetch.

Unlock the depth
Staff
Locked

Timeout budgets for each phase of a transfer, the rule about only retrying before the first byte, compression passthrough, and the fd metrics that catch abort leaks.

Unlock the depth
Follow-up chain
Say you have to proxy a big HTTP response through your service without buffering the whole thing. How do you do it, and what actually breaks if you get it wrong? | NodeBook