60 mins System Design Interview Framework

A system design interview is 45 to 60 minutes of a deliberately open-ended problem, and the fastest way to fail it is to wander - spend 25 minutes clarifying, or dive straight into database schemas and never surface. There is a repeatable four-step framework that fits the hour, and a rough time budget for each step. This post is the map: it ties together everything in the System Design Guide series and shows you where each piece belongs in the 60 minutes.

Why you need a plan at all

The problem ("design Twitter") is broad on purpose, and the clock is short. Without a structure you will over-invest in whatever feels comfortable and run out of time before you show the skills being graded: scoping, sound architecture, and reasoning about trade-offs. The framework exists so you always know what to do next and how much time it deserves - which frees your attention for the actual thinking.

The four steps are the same for every problem:

Step	What you do	~time (of 60 min)
1. Scope the problem	Clarify requirements, agree features, rough estimates	~10 min
2. High-level design	Draw the components, define the APIs, get buy-in	~15 min
3. Deep dive	Go deep on the 1-2 hardest components and trade-offs	~25 min
4. Wrap up	Bottlenecks, failures, scaling, recap	~5-10 min

For a 45-minute session, squeeze each proportionally (roughly 5 / 10 / 25 / 5). The exact split flexes with the problem and how the interviewer steers - treat it as a budget, not a stopwatch.

Step 1 - Scope the problem (about 10 minutes)

Do not design anything yet. Turn the vague prompt into a scoped one by asking clarifying questions, split into two buckets: functional requirements (what the system does) and non-functional ones (scale, latency, availability, consistency). This is the single most important habit in the whole interview - the first thing to do is refuse to jump to a solution.

Pin down the two or three core features, agree what is out of scope, and get the scale numbers. Then do a quick back-of-the-envelope estimate - QPS and storage - so the design that follows is anchored to real numbers instead of a guess. Write the agreed scope and the key figures somewhere visible; they are the contract for the rest of the hour. Keep this under ten minutes: scope too little and you design blind, linger too long and you have no time to design at all.

Step 2 - Sketch the high-level design and get buy-in (about 15 minutes)

Now draw the architecture: the boxes and the arrows. A typical sketch has clients, a load balancer, stateless services, a database, a cache, maybe a message queue and a CDN - the core building blocks you assemble to fit the requirements. Define the handful of API endpoints the features imply, and show the main data flow through the system.

The critical word in this step is buy-in. Present the blueprint, then explicitly check: "does this overall shape look right before I go deeper?" Treat the interviewer as a teammate - good ones will nod, redirect, or hint at where they want you to focus. That nod is your license to go deep, and it means everything you build next stands on agreed ground. Do not descend into one component yet; get the whole picture agreed first.

Step 3 - Deep dive the hard part (about 25 minutes)

This is the largest slice and where most of the signal is. You and the interviewer pick the one or two most interesting components and go deep - the parts where the real engineering lives. For a URL shortener that is the hashing and collision handling; for a chat app, delivery latency and online presence; for a feed, the fanout and the celebrity problem.

Going deep means showing the mechanism and the trade-offs: SQL vs NoSQL and why, strong vs eventual consistency and what it costs, push vs pull for a feed. Never present a choice as the only option - name the alternative and say why you picked this one. Let the interviewer steer; if they push on a specific area, that is where they want to see depth. Watch the time here above all, because it is the easiest step to rabbit-hole in - talking about one clever detail for ten minutes that does not prove you can design a system.

Step 4 - Wrap up (the last 5 to 10 minutes)

Leave time for this; a strong close changes the final impression. Identify the bottlenecks in your own design - never claim it is perfect, because there is always something to improve, and spotting it yourself is exactly the critical thinking they want. Touch on failure modes (a server dies, the network partitions), operations (how you monitor and roll out), and the next scale curve (what changes to go from 1 million to 10 million users). A quick recap of the design ties it together, especially after a long session.

Reading the clock

Time management is the skill being tested as much as the design. A few rules keep you on track:

• Cap step 1 at ~10 minutes. It is load-bearing but short; get the nod on scope and move.
• Get buy-in before deep-diving. Designing the wrong component in detail is wasted time you cannot get back.
• Protect the wrap-up. If you are 50 minutes in and still deep in one component, pull up and summarize - finishing the arc beats perfecting one corner.
• Narrate throughout. The interviewer can only grade what they hear; think out loud, and if you go blank, say so and fall back to the framework rather than freezing in silence.

The dos and don'ts, condensed

Do: always clarify before designing; communicate every decision out loud; suggest more than one approach and defend your pick; design the most critical component first; treat the interviewer as a collaborator; ask for a hint if you are stuck.

Don't: jump to a solution without scoping; go deep on one component before the high-level design is agreed; over-engineer for scale you were not asked for; think in silence; or assume you are finished - you are not done until the interviewer says so, so ask for feedback early and often.

You now have the spine of the hour

The whole interview is four steps on a budget: scope in ~10, sketch and agree in ~15, deep-dive the hard part in ~25, wrap up in the last ~10. Everything else in this series fills in a step - clarifying questions and requirements for step 1, the concepts and building blocks for step 2, the low-level design work for the deep dive. Internalize the shape, keep half an eye on the clock, and an open-ended hour stops being intimidating and becomes a checklist you work through.

With the framework in hand, the series turns to putting it to work: taking a real prompt - starting with the classic URL shortener - and walking it end to end through all four steps. The framework here follows the one laid out in Alex Xu's System Design Interview.