System design interview questions are rarely about finding the perfect architecture. Instead, they’re about understanding trade-offs, clarifying requirements, and communicating your thinking clearly.
A classic example looks like this:
“When a user clicks the Load Report button, it takes several minutes to generate. How would you improve this experience?”
At first glance, this sounds like a performance problem. But if you jump straight into optimisations without stepping back, you’ll likely miss what the interviewer is really testing. This post walks through how to approach questions like this in a structured, thoughtful way.
A common mistake in system design interviews is assuming that slow = performance bug.
In this example, the report takes several minutes to generate. That may be perfectly reasonable. Reports often involve:
Aggregating large datasets
Running expensive queries
Performing calculations or transformations
Pulling data from multiple systems
If the system is currently implemented with synchronous processing, the flow likely looks like this:
User clicks Load Report
Frontend sends a request to the backend
Backend starts generating the report
The request stays open until the report finishes
Backend returns the result
This approach has several issues:
The user is stuck waiting with no feedback
Requests can time out
Server resources are tied up for long-running operations
Scaling becomes difficult as concurrent users increase
Importantly, the problem isn’t that the report generation is slow — it’s that the user experience and system design don’t match the nature of the work.
Once you recognise that report generation is a long-running task, asynchronous processing becomes a natural direction to explore.
Asynchronous designs allow you to:
Decouple request handling from heavy processing
Free up web servers quickly
Provide immediate feedback to users
Scale background work independently
In interviews, this is often the “aha” moment the interviewer is looking for. You’re demonstrating that you can:
Identify long-running operations
Choose appropriate architectural patterns
Improve UX without pretending expensive work is cheap
At this point, it’s useful to talk through high-level concepts like queues, background workers, and eventual completion — before diving into specific technologies.
One possible design could look like this:
Web API
The user clicks Load Report
The frontend calls a Web API endpoint
The API:
Creates a report request
Pushes a message onto a queue
Immediately returns an HTTP 202 Accepted response
This tells the client: “Your request is valid and is being processed.”
Queue
Acts as a buffer between the web layer and the processing layer
Smooths traffic spikes
Allows retries and failure handling
Cloud Function (or background worker)
Listens to the queue
Pulls report generation jobs
Performs the heavy computation
Writes the completed report to Blob Storage
Blob Storage
Stores the generated report
Cheap, scalable, and durable
Allows the report to be downloaded later without regenerating it
SignalR (or similar real-time mechanism)
When the report is ready, the system notifies the user in real time
The UI updates to show a “Download Ready” state
No polling required
This design:
Improves user experience immediately
Scales well under load
Keeps components loosely coupled
Handles failures more gracefully
In an interview, you don’t need to name specific cloud services unless asked — but showing how the pieces fit together is critical.
This question is popular because it tests several important skills at once:
Requirement clarification
Is latency acceptable? Does the user need the result immediately?
Architectural thinking
Can you recognise when async processing is appropriate?
Trade-off discussion
Complexity vs. user experience, real-time notifications vs. polling, storage costs, and operational overhead
Communication
Can you explain your reasoning clearly and incrementally?
There’s no single “correct” answer — and that’s the point.
When approaching system design interview questions:
Don’t jump straight to optimisation
Understand why the system behaves the way it does
Identify long-running or expensive operations
Consider asynchronous designs when appropriate
Focus on user experience and system scalability
Clearly explain trade-offs and reasoning
System design interviews reward thinking, not memorisation. If you can guide the interviewer through your thought process using a simple example like a slow report generation, you’re already on the right track.