Architecture scenarioHard~12 minHTTP API Semantics / 9 of 11

Interview question

An API must return a multi-gigabyte export. How would you stream the response without buffering it all in memory?

Stream large HTTP responses without buffering

Designs cancellation-aware response streaming with bounded memory, correct resource ownership, and practical download behavior.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I produce or open the content as a stream and let the server copy it to the response asynchronously instead of building one byte array or string. In ASP.NET Core a file or stream result can own that transfer. I set the media type and download name, propagate request cancellation, and make ownership clear so the stream and any temporary file are disposed after the response finishes or the client disconnects.

Full answer below

Practice focus

Response streaming, FileStreamResult, async writes, cancellation, backpressure, ranges, compression, timeouts, object storage, and cleanup.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Large responses change the resource boundary of a request. A design that materializes the whole payload can exhaust memory long before network throughput becomes the visible bottleneck.
I produce or open the content as a stream and let the server copy it to the response asynchronously instead of building one byte array or string. In ASP.NET Core a file or stream result can own that transfer. I set the media type and download name, propagate request cancellation, and make ownership clear so the stream and any temporary file are disposed after the response finishes or the client disconnects.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
If the size is known I can send Content-Length; otherwise the HTTP version handles response framing while the application writes incrementally. Backpressure means writes should await the transport rather than generating data without bound. Range support helps clients resume static or seekable downloads, but it needs correct length and seek behavior. On-the-fly compression may consume substantial CPU and can be wasteful for already compressed formats. Long downloads need timeouts and rate limits that distinguish healthy slow transfer from a stuck producer.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
For expensive exports I often separate generation from download: enqueue a job, store the result durably, and return a status resource followed by a short-lived object-storage URL. That isolates API workers and makes retries or resume behavior clearer. Direct streaming still needs bounded database reads, cancellation through every layer, disconnect handling, and cleanup that survives process failure. I monitor generation time, first-byte latency, bytes sent, cancellation, temporary storage, and concurrent streams. Load tests use realistic slow clients because fast local downloads hide memory and connection pressure.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Calling ToArray or building one giant string before writing the response.
Ignoring cancellation after the client disconnects.
Disposing the source stream before the framework finishes the response.
Enabling compression for every large binary format without measurement.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

A few concurrent exports can consume all process memory or connections.
Temporary files remain after failures or restarts.
The producer outruns the network with no bounded buffering.
A synchronous export holds a request open for work better owned by a job.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When would you return a job ID instead of streaming directly?
How does backpressure affect the producer?
What is required to support range requests?

Continue the section

Next in HTTP API Semantics: Retry signals and budgets

Step 10 of 11

Retry-After, timeouts, and safe client retries

Opening drill

Architecture scenarioHard~12 minHTTP API Semantics / 9 of 11

Interview question

An API must return a multi-gigabyte export. How would you stream the response without buffering it all in memory?

Stream large HTTP responses without buffering

Designs cancellation-aware response streaming with bounded memory, correct resource ownership, and practical download behavior.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Response streaming, FileStreamResult, async writes, cancellation, backpressure, ranges, compression, timeouts, object storage, and cleanup.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Large responses change the resource boundary of a request. A design that materializes the whole payload can exhaust memory long before network throughput becomes the visible bottleneck.
I produce or open the content as a stream and let the server copy it to the response asynchronously instead of building one byte array or string. In ASP.NET Core a file or stream result can own that transfer. I set the media type and download name, propagate request cancellation, and make ownership clear so the stream and any temporary file are disposed after the response finishes or the client disconnects.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
If the size is known I can send Content-Length; otherwise the HTTP version handles response framing while the application writes incrementally. Backpressure means writes should await the transport rather than generating data without bound. Range support helps clients resume static or seekable downloads, but it needs correct length and seek behavior. On-the-fly compression may consume substantial CPU and can be wasteful for already compressed formats. Long downloads need timeouts and rate limits that distinguish healthy slow transfer from a stuck producer.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
For expensive exports I often separate generation from download: enqueue a job, store the result durably, and return a status resource followed by a short-lived object-storage URL. That isolates API workers and makes retries or resume behavior clearer. Direct streaming still needs bounded database reads, cancellation through every layer, disconnect handling, and cleanup that survives process failure. I monitor generation time, first-byte latency, bytes sent, cancellation, temporary storage, and concurrent streams. Load tests use realistic slow clients because fast local downloads hide memory and connection pressure.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Calling ToArray or building one giant string before writing the response.
Ignoring cancellation after the client disconnects.
Disposing the source stream before the framework finishes the response.
Enabling compression for every large binary format without measurement.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

A few concurrent exports can consume all process memory or connections.
Temporary files remain after failures or restarts.
The producer outruns the network with no bounded buffering.
A synchronous export holds a request open for work better owned by a job.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When would you return a job ID instead of streaming directly?
How does backpressure affect the producer?
What is required to support range requests?

Continue the section

Next in HTTP API Semantics: Retry signals and budgets

Step 10 of 11

Retry-After, timeouts, and safe client retries

An API must return a multi-gigabyte export. How would you stream the response without buffering it all in memory?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

An API must return a multi-gigabyte export. How would you stream the response without buffering it all in memory?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section