Design a .NET backend feature where users request large CSV or PDF reports and download them later. How would you structure it?

Design a backend for large report exports

Designs an async export flow for large reports without blocking API requests or exhausting database and memory resources.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would avoid generating a large report inside the HTTP request. The API would create an export job record, validate the user's permission, enqueue a message with the job id, and return a status URL. A worker would load the data in pages or streams, generate the file, store it durably, and mark the job complete with a download link. The user can poll or receive a notification when the export is ready.

Full answer below

Practice focus

Async workflow design, job state, data access, storage, queue processing, progress, failure handling, and operational controls.

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 exports combine API latency, data volume, background processing, storage, authorization, and user-visible progress. The request path must stay bounded while the generated artifact remains durable and securely retrievable.
I would avoid generating a large report inside the HTTP request. The API would create an export job record, validate the user's permission, enqueue a message with the job id, and return a status URL. A worker would load the data in pages or streams, generate the file, store it durably, and mark the job complete with a download link. The user can poll or receive a notification when the export is ready.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would model job states explicitly: queued, running, completed, failed, expired, and cancelled. The worker would use bounded concurrency so exports do not starve normal API traffic or overload SQL Server. For large datasets, I would avoid loading everything into memory and design the query path around indexes, stable ordering, and checkpoints. The API would expose progress, safe retry, cancellation, expiration, and access checks on every download attempt.

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

Generating the whole file in the request thread.
Loading all rows into memory before writing the file.
Skipping permission checks on the final download URL.
No retention or cleanup plan for generated files.

Design a .NET backend feature where users request large CSV or PDF reports and download them later. How would you structure it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Technologies

Tech stacks

Skill areas

Suggest an improvement