System design interviews
A practical way to structure a system design interview
Original guide by MockInterview AI · Updated 12 September 2026
A system design interview is not a contest to name the most infrastructure. It is a conversation about making sensible engineering decisions with incomplete information. The most useful answers begin by narrowing the problem, then add complexity only when a stated requirement creates a reason for it.
Open by defining the job of the system
Ask what the system must let a user do, who is using it, and what is explicitly out of scope. For a URL shortener, you might clarify whether links can expire, whether users need analytics, and whether redirects must work globally. Repeating the agreed scope gives the interviewer a chance to correct assumptions before the diagram becomes expensive to change.
Turn vague scale into a rough budget
You do not need exact numbers. Estimate requests per day, convert that to average requests per second, and call out a plausible peak multiplier. Then identify which path is read-heavy or write-heavy and which data must be durable. For example, a short-link redirect may have many more reads than writes, which suggests protecting the read path with caching while keeping link creation simple and reliable.
Draw the smallest end-to-end path first
Name the client, an API or load balancer, the application service, and the durable store. Walk through one request from start to finish before adding queues, replicas, or event streams. A simple flow makes it possible to explain ownership: the service validates the request, the database stores the mapping, and the redirect endpoint resolves it. If the core path is unclear, extra components only hide the uncertainty.
Choose data around the access pattern
State the key you need to look up and the record that must come back. In the URL example, a short code maps to a destination URL, creator identifier, timestamps, and optional expiration. Explain why a key-value lookup or indexed relational table suits that request. If you introduce a cache, specify what it stores, its expiration behavior, and what happens on a miss.
Name the failure that each extra component handles
A replica helps when the primary database is unavailable or reads need more capacity. A queue helps when work can be delayed, such as aggregation of click analytics. A cache helps when the same mapping is requested repeatedly. This “component to failure mode” habit is more convincing than adding familiar technologies by default, and it shows that you understand the operational cost of every choice.
Close with risks, observability, and a next decision
Finish by naming a few signals you would watch: redirect latency, cache hit rate, database errors, and the rate of invalid or abusive links. Mention one trade-off you would revisit if the product changed, such as stronger consistency for link edits or regional storage for lower latency. A thoughtful close demonstrates that design continues after the first deployment.
Prompts to practice
- Design a service that lets users save and search personal notes.
- How would you scale a notification system from one reminder type to several channels?
- Design an image-upload flow and explain where you would scan, store, and deliver files.
Use the framework as a starting point, then adapt it to your own experience and voice.
Practice this framework