Your team proposes making streamed HTML the default for every server-rendered route in the application. As the engineer deciding, what would make you push back on some of those routes?
answer
- value scales with server think time
- first flush commits status and headers
- decision routes have nothing to stream
- cacheable whole beats streamed from origin
- complexity that regresses silently
basics
~20 sStreaming commits the status and headers at the first flush, so error handling, redirects and cookie setting have to be settled before it. It also complicates full-page caching and adds complexity that only pays off on routes with real server think time.
solid answer
~60 sStreaming is a good default for slow, dynamic, content-heavy routes and a poor one everywhere else. The hard constraint is that flushing the first chunk commits the status line and headers: after that the route cannot return a 500, redirect, or set a session cookie, so any failure discovered mid-render has to be expressed inside an already-successful page. That rules out routes whose main job is a decision — auth callbacks, redirect handlers, form posts. The second issue is caching: a fully cacheable page gets far more from being served whole from an edge than from being streamed from origin, and some intermediaries buffer streamed responses anyway, silently removing the benefit. The third is that streaming only pays where there is server think time to overlap; a route that renders in 20 ms gains nothing measurable and still carries the restructured data flow, per-region error states and extra failure modes. My rule would be: stream where the page has genuinely slow regions and useful content to show first, keep the rest simple.
go deeper
Know that once the server has sent the first part of a streamed page it cannot change the response status or redirect, so some routes are better sent as one complete response.
Explain the concrete constraints: headers commit at the first flush, deferred regions need their own error states, and a route with no slow data has nothing to gain from streaming.
Show that you would resolve failure paths before the first flush, verify streaming survives the intermediaries in production, and give each deferred region a defined failure state rather than a permanent skeleton.
Own the policy: define which route classes stream and why, protect cacheability from being traded away for a smaller win, assert the property in CI or synthetics, and push to remove the slow dependency before paying complexity to hide it.
## Start from what streaming buys Streaming converts server think time into browser work time. Its value is therefore proportional to how much think time there is and how much useful content can be shown before it ends. A route with 600 ms of data fetching and a rich shell above it is an excellent candidate. A route that renders from memory in 20 ms has nothing to overlap, and the change is pure cost. That framing — value proportional to think time — is what turns "stream everything" from a policy into a case-by-case decision. ## The hard constraint: headers commit at the first flush The status line and response headers go out with the first chunk. From that instant the route has promised a 200 and whatever headers it sent. It can no longer: - turn the response into a 500 when a later query throws; - issue a redirect discovered mid-render; - set an authentication or session cookie; - change caching headers based on what it found while rendering. This is not fatal — a streamed page can render a failed region inline, and most applications learn to validate and decide before the first flush — but it changes where those concerns live. Routes whose *entire purpose* is a decision (an auth callback, a payment return, a POST handler that redirects) have nothing worth streaming and everything to lose, so they should stay buffered. A middle path is worth naming: flush only after the checks that can fail cheaply. Authenticate, authorise, resolve the redirect, then flush the shell and stream the slow content. That preserves most of the benefit while keeping the failure modes that actually occur on the buffered side of the line. ## Caching pulls the other way The fastest dynamic page is one that did not need the origin at all. If a route can be cached whole at an edge, that beats streaming from origin on almost every metric, and mixing the two is awkward: a personalised streamed response is not shareable, and many intermediaries buffer responses in order to cache them, which quietly erases the streaming you paid for. On routes where the shell is cacheable and only a small region is personal, the better architecture is often a cached page plus a separate request for the personal part — not a streamed personalised document. This is also where a "stream everything" policy does real damage: it can push teams toward per-request rendering on pages that were previously fully cacheable, trading an enormous win for a modest one. ## Complexity is a real cost Streaming forces the handler to stop being a single render call. Data fetches must start before rendering, the template must be emitted in pieces, and every deferred region needs its own loading and failure state. Each of those is a place to get it wrong under conditions that only appear in production — a region that fails after headers are committed and leaves a permanent skeleton, a placeholder sized wrong that shifts the layout, a proxy that buffers on one route and not another. And it can regress silently: a buffered page is still correct, just slower, so nothing fails when a new middleware wraps the response. That argues for streaming being a deliberate, tested property on a named set of routes, with a synthetic check asserting it, rather than an ambient default nobody verifies. ## How I would set the policy Stream when all of these hold: the route has server think time worth overlapping, there is meaningful content that can be shown before the slow data resolves, the route cannot be cached whole, and the failure paths can be resolved before the first flush. Do not stream when: the route is a decision or a redirect, it is fully cacheable at the edge, it renders fast enough that the overlap is imperceptible, or the path to the user contains an intermediary that will buffer it anyway. And sequence it honestly. Streaming is a scheduling improvement; it does not make a slow query faster. If the underlying 900 ms dependency can be cached, precomputed or parallelised, that work usually beats the streaming project outright and makes the streaming that remains cheaper to reason about. The strongest version of the pushback is not "streaming is risky" — it is "on these routes we would be paying complexity to hide a problem we could remove."
- How do you keep most of the streaming benefit while preserving normal error handling?Move the decisions before the first flush. Authenticate, authorise, validate input and resolve any redirect while the response is still buffered, then flush the shell and stream the slow regions. Failures that occur after that point are, by design, the rarer ones — and they get an inline error region rather than a status code.
- Why can a fully cacheable page be a bad candidate for streaming?Because serving it whole from an edge removes the origin from the path entirely, which beats overlapping origin think time. Streaming a personalised response also makes it unshareable, and intermediaries that buffer in order to cache will erase the streaming anyway. The better split is a cached shell plus a separate request for the personal fragment.
- How would you stop a streaming policy from quietly decaying?Name the routes that must stream, assert the property with a synthetic check comparing time to first byte against total transfer time, and treat any new response-wrapping middleware as a review flag. A buffered page still renders correctly, so nothing else will fail when the property is lost — it has to be tested for explicitly.
saying these in an interview costs you the question
- Treats streaming as free with no failure-mode cost
- Streams routes whose purpose is a redirect or a decision
- Converts cacheable pages to per-request streamed rendering
- Assumes every intermediary preserves streaming
- Presents streaming as a fix for a slow backend dependency