System designHard~20 minSystem Design Foundations Essentials / 6 of 15

Interview question

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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would treat exports as a workload with its own capacity and abuse controls. I would limit export size, per-user concurrency, retention time, and total storage. The design would include idempotent job creation, retry-safe workers, poison handling, audit trails for sensitive exports, and telemetry for queue age, job duration, failure reason, file size, and database pressure. If the report depends on a snapshot, I would define whether it reflects request time, completion time, or a documented reporting cutoff.

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.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain job states or retry behavior.
Ignores database load from reporting queries.
Has no answer for cancellation, expiration, or failed exports.
Treats background work as fire-and-forget from the controller.

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.

How would you prevent one user from starting too many exports?
How would progress reporting work?
What happens if the worker crashes halfway through the file?

Continue the section

Next in System Design Foundations Essentials: Notification System

Step 7 of 15

Design a notification system for a .NET backend

Opening drill

System designHard~20 minSystem Design Foundations Essentials / 6 of 15

Interview question

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

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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would treat exports as a workload with its own capacity and abuse controls. I would limit export size, per-user concurrency, retention time, and total storage. The design would include idempotent job creation, retry-safe workers, poison handling, audit trails for sensitive exports, and telemetry for queue age, job duration, failure reason, file size, and database pressure. If the report depends on a snapshot, I would define whether it reflects request time, completion time, or a documented reporting cutoff.

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.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain job states or retry behavior.
Ignores database load from reporting queries.
Has no answer for cancellation, expiration, or failed exports.
Treats background work as fire-and-forget from the controller.

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.

How would you prevent one user from starting too many exports?
How would progress reporting work?
What happens if the worker crashes halfway through the file?

Continue the section

Next in System Design Foundations Essentials: Notification System

Step 7 of 15

Design a notification system for a .NET backend

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 the section

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 the section