The System Design Interview Framework: A Repeatable Method for Any Problem

Most people who struggle in system design interviews do not lack knowledge. They know what a cache is and what sharding means. What goes wrong is structure: they start drawing before they understand the problem, spend twenty minutes on a part the interviewer does not care about, forget to estimate, never mention failures, and run out of time before saying what their design actually is.

This article gives you a structure you can rely on under pressure. It is the seven-phase method from article 01, expanded into a 21-item checklist with a time plan, the phrases that make your reasoning visible, and a clear picture of what changes between SDE-1 and SDE-2 rounds. Every case study that follows uses it.

• What system design interviewers typically evaluate.
• The 21-item checklist, grouped into the seven phases.
• A time plan for 45-minute and 60-minute interviews.
• Phrases for clarifying, estimating, deciding and summarising.
• How to handle hints, pushback and getting stuck.
• How SDE-1 and SDE-2 expectations differ.
• A compact worked example: a game leaderboard.
• How to practise.

Rubrics differ between companies and interviewers, and change over time, so treat this as a general picture rather than any company's official criteria. Most system design evaluations look for evidence of:

Notice what is not on the list: naming many technologies, or reproducing a famous company's architecture. Interviewers look for observable reasoning.

You will not always cover all 21 in depth. The checklist is a map: it reminds you what exists, so you can choose consciously what to skip ("I'll skip detailed security unless you'd like me to cover it") rather than forgetting it.

Roughly: a quarter of the time on understanding and framing, a third or more on scaling and depth. If the interviewer cuts in to steer towards a deep dive earlier, follow them; the plan is a default, not a script.

Keep the first sections similar (they do not need to grow much) and give the extra time to deep dives: a second component in depth, a failure walkthrough, or a follow-up requirement ("now make it multi-region").

Restate the problem in one sentence, then ask questions that change the design (article 02 has a reusable list).

"To make sure I understand: we're building a service that turns long URLs into short ones and redirects people who visit the short link. Can I ask a few questions first?"

Then write requirements down, numbered, so you can refer to them:

"Functional: 1, create a short link; 2, redirect; 3, optional custom alias; 4, optional expiry. Out of scope: analytics dashboards and user accounts, unless you'd like them. Non-functional: redirects under 50 ms at p99, very high availability for redirects, links never silently point to the wrong place."

Mark the one or two requirements that will drive the design: "this is extremely read-heavy, so the redirect path is where most of the design effort goes."

State assumptions, compute, and draw a conclusion (articles 06 and 07).

"Assume 100 million new links a month and a 100-to-1 read-to-write ratio. That's about 40 writes a second and 4,000 reads a second on average; with a peak factor of 3, 12,000 reads a second. Each link is about 500 bytes, so 50 GB a month, 600 GB a year: one database can hold years of it. The read rate says we want a cache."

Keep it to two or three minutes. If the interviewer says "skip estimation", skip it gracefully.

"Two main endpoints: POST /v1/links with the long URL and optional alias, returning 201 and the short code; and GET /{code}, returning a redirect. Creation should take an idempotency key so retries don't create duplicate links."

"One main table keyed by short code, since every redirect looks up by code. Columns: code, long URL, owner, created and expiry times. The access pattern is a point lookup by primary key, which also means it shards cleanly by code if we ever need to."

Draw the simplest thing that works, then walk a request through it:

"Client to load balancer to stateless app servers to the database. For a redirect: the server receives GET /abc123, looks up the code, and returns a 302 with the location. Now let's see what breaks first at 12,000 reads a second."

The baseline matters because it shows you can design without reflexively adding every component, and it gives the rest of the interview a clear starting point.

Use the three questions from article 01 aloud:

"What breaks first? Reads: 12,000 per second of point lookups on a hot subset. I'll add a cache in front of the database (cache-aside, TTL of a day, since links rarely change). With a 95% hit ratio the database sees about 600 reads a second."

Each addition gets a reason tied to a number or a requirement. Repeat until the interviewer is satisfied or steers you to a deep dive.

Walk through failures, consistency, security and observability briefly but explicitly:

"If the cache fails, the database would see 12,000 reads a second, which it can't sustain, so we'd shed load and serve popular links from a small in-process cache. If the primary fails, a synchronous standby takes over within a minute; redirects keep working from replicas and cache. Consistency: a newly created link must work immediately for its creator, so we write through to the cache on creation..."

Every important decision should sound like this, with three parts:

"I chose X. It costs Y. That's acceptable here because Z."

For example: "I chose a 302 redirect rather than 301. It costs us more requests, because browsers won't cache the redirect permanently. That's acceptable because we want to count clicks and be able to change or expire links."

In under two minutes: the requirements you designed for, the architecture in one breath, the two or three key decisions and their trade-offs, the main risks and what you would do next.

• Hints are gifts. If the interviewer asks "what happens when this key gets very popular?", they are steering you to a deep dive. Go there.
• Pushback is not a verdict. "Why not just use a NoSQL store?" usually means "explain your reasoning". Restate your reasons; if their point is better, adopt it openly: "That's a good point; given the access pattern is only by key, a key-value store would also fit, and I'd choose based on what the team already operates."
• When stuck, go back to the requirements and numbers: "Let me look at what we need: 12,000 reads a second, mostly repeated. That suggests..."
• Check in at transitions: "I have a baseline. Shall I go into scaling the reads, or would you like to see the data model in more detail first?"
• Do not go silent. Thinking aloud lets the interviewer follow and help.

• Draw boxes for components and label the arrows (what flows).
• Distinguish the request path (synchronous) from the asynchronous path (queues and workers), for example with dashed lines or separate rows.
• Show data stores explicitly, with what they hold.
• Evolve one diagram as you scale, rather than drawing a new one, so the interviewer sees the history of decisions.

Interview levels and expectations vary by company; the comparison below is a general guide.

Here is the framework applied briefly to "design a leaderboard for a mobile game", to show the shape. The full case studies that follow are much deeper.

Clarify. Players submit scores after each match; the app shows the global top 100 and the player's own rank. Questions: one global board or per region and per season? (Per season, global.) How fresh must ranks be? (Within a few seconds.) Ties? (Earlier score ranks higher.) Out of scope: friends' leaderboards, anti-cheat details.

Estimate. Assume 5 million daily players, 10 matches each: 50 million score submissions a day, about 580 per second on average, about 1,700 at a peak factor of 3. Reads of the top 100 and "my rank": assume 20 per player per day, 100 million a day, about 1,200 per second average, 3,500 peak. A season has up to 20 million players: one entry each (player id and score) is small.

Interface. POST /v1/seasons/{seasonId}/scores (idempotency key per match id), GET /v1/seasons/{seasonId}/leaderboard?limit=100, GET /v1/seasons/{seasonId}/players/{playerId}/rank.

Data. Durable store: match_results(match_id PK, player_id, season_id, score, finished_at), the source of truth. Ranking structure: a sorted set per season, member = player id, score = best score (with a tie-breaker encoded). Redis sorted sets keep members ordered by score and support range queries and rank lookups efficiently, which is exactly this access pattern (Redis sorted sets).

Baseline. Game servers call the score API; the API writes the match result to the database and updates the player's best score in the sorted set if higher; reads come from the sorted set.

Scale. 1,700 writes and 3,500 reads per second are well within one in-memory sorted set's comfortable range on suitable hardware (to be confirmed by load testing); 20 million members fit in memory. The top 100 is the same for everyone, so cache it for one second, cutting most of the read load.

Harden. If the sorted set is lost, rebuild it from match_results (a job reads each player's best score for the season). Duplicate submissions are harmless because match_id is unique. Consistency: a player's own rank may lag by a second; acceptable per requirements. Security: only game servers (authenticated service identities) may submit scores, never clients directly, which blocks trivial cheating. Observability: submission rate, sorted-set update latency, rank-query p99. Trade-off: an in-memory ranking structure gives fast, simple ranks at the cost of rebuild time after a failure; a replica of the sorted set reduces that risk.

Summary. "Scores are stored durably by match and folded into a per-season sorted set keyed by player; reads serve top-N and rank directly from it with a short cache on the top 100. Idempotency by match id prevents double counting; the sorted set is rebuildable from the durable store."

1. Solo, timed. Pick a problem, set a 45-minute timer, and talk through it aloud while writing notes and diagrams. Record yourself if you can.
2. Compare with a reference. After finishing, read the matching case study in this course and list what you missed.
3. Score yourself with the rubric in article 45.
4. Mock interviews with a friend or peer, taking turns as interviewer. Interviewers learn as much as candidates.
5. Repeat problems after a week or two. The goal is fluency with the method, so new problems feel familiar.

• Spending 15 minutes on requirements and running out of time.
• Estimating everything instead of the numbers that matter.
• Designing the final architecture first and justifying it backwards.
• Ignoring the interviewer's hints because they are not in your plan.
• Never summarising.
• Treating the interview as a quiz rather than a collaborative design session.

The checklist is also a protection against a quieter failure: a perfectly reasonable design with no stated trade-offs, which leaves the interviewer unable to see your judgment.

• Next: Design a URL Shortener (and Pastebin): A Complete Walkthrough, the first full case study using this framework.
• For the interview round as a whole: Software Interview Preparation: A 6-Week Plan That Actually Works covers coding and behavioural preparation alongside system design.