System Design Interview Framework

A system design interview gives you an open question, such as "design a URL shortener" or "design a chat app", and about 45 minutes. There is no single correct answer. What the interviewer is really assessing is how you work: whether you clarify the problem, make sensible trade-offs and explain them clearly. A simple, repeatable framework is the most reliable way to show that under time pressure.

The common mistake: drawing boxes immediately

The natural instinct is to start drawing a load balancer, servers and a database within the first minute. This tends to go wrong in three ways:

• You solve the wrong problem. Without asking, you do not know whether the system serves a thousand users or a billion, or which features matter.
• You run out of time. Early detail on unimportant parts leaves no time for the parts the interviewer cares about.
• You show no reasoning. A design without stated assumptions and trade-offs looks memorised rather than thought through.

The four steps

The timings above are a typical split for a 45-minute interview; treat them as a guide, not a rule.

Step 1: understand the problem and agree the scope

Ask questions before designing anything. The question is deliberately vague, and your questions show how you think.

• Users and features. Who uses it, and what must it do? Which features are out of scope today?
• Scale. How many users, how many requests, how much data? This decides almost everything else (see Back-of-the-Envelope Estimation).
• Read and write mix. Is it read-heavy, like a news feed, or write-heavy, like a logging system?
• Quality requirements. How fast must it respond? Can it ever show slightly old data? How bad is downtime?

Write the answers down where the interviewer can see them. They become the yardstick for every later decision.

Step 2: propose a high-level design and get agreement

Draw the main components and how a request flows through them. Keep it simple and walk through one or two key user actions from start to finish. Then check with the interviewer that this shape makes sense before going further. Agreeing now avoids spending twenty minutes on a design they would have redirected.

Step 3: go deep on two or three parts

You cannot design everything in detail, so choose the parts that matter most for this problem, or follow the interviewer's lead. Typical candidates: the data model, how a key operation works, caching, how the data is split across machines, or what happens when a component fails. Depth here is what demonstrates engineering judgement; a long list of technologies without depth does not.

Step 4: wrap up

Use the last few minutes to review your own design honestly:

• Where is the bottleneck, and what breaks first at ten times the load?
• What did you simplify, and what would you change with more time?
• How would you monitor it and know it is healthy?

A worked example: a URL shortener

Here is the framework applied to a common question, at the level of detail of steps 1 and 2.

Step 1, scope. Users submit a long URL and receive a short one; visiting the short URL redirects to the original. Suppose 100 million new URLs a month, and each one is read about 10 times as often as it is created. Short links never expire, and redirects should be fast.

Step 2, high-level design.

• Write: the client sends the long URL; a web server generates a unique short code, stores the pair in the database and returns the short URL.
• Read: the client requests the short code; the web server checks the cache, falls back to the database, and responds with a redirect.
• Because reads far outnumber writes, a cache in front of the database carries most of the load.

Step 3 candidates. How to generate short codes that never collide, how to size the database over five years, and what happens if the cache fails.

Step 4. The database becomes the limit as data grows, so it would eventually be split across machines; popular links might be served from a CDN.

What interviewers are looking for

• Clarity. You define the problem before solving it.
• Trade-offs. You explain why you chose one option over another, and what it costs.
• Communication. You think aloud and involve the interviewer.
• Judgement. You spend time on the parts that matter.

A straightforward design with clear reasoning usually scores better than a sophisticated one presented without explanation.

Implementing it in your project

Use the same four steps before building any non-trivial feature, written down as a one-page design document:

1. Scope: who uses it, what it must do, what is out of scope, expected numbers.
2. High-level design: a diagram of the components and one request traced through it.
3. Deep dive: the data model and the one or two hardest parts.
4. Trade-offs: what you chose, what you rejected and why, and what would change at ten times the load.

Reviewing that page with a teammate before writing code catches most design mistakes when they are still cheap to fix.

---

Sources and credibility

Method

• The four-step structure (understand the problem and establish the scope, propose a high-level design and get agreement, design deep dive, wrap up) follows Alex Xu's System Design Interview, Vol. 1, chapter 3. The explanations, timings and the worked example are our own.

On copyright: the diagrams on this page were drawn for this article, and the explanations are original.