System Design Interview: How to Structure Your 45 Minutes

Quick Answer

A 45-minute system design interview isn't graded on whether you draw the “correct” architecture — it's graded on process: how you scope an ambiguous prompt, estimate real numbers, and defend trade-offs as the conversation moves. The rough time budget is 5–8 minutes on requirements, 10–15 on high-level design, 15–20 on a deep dive (where most of the scoring weight sits), and 5–10 wrapping up with trade-offs. Most candidates who know the concepts still fail this round on process, not knowledge.

This Round Grades Process, Not the Final Diagram

System design prompts (“design Twitter,” “design a URL shortener,” “design a ride-hailing dispatch system”) are deliberately open-ended. There is no single correct architecture the interviewer is checking your diagram against — there's a rubric, and it scores how you operate under ambiguity, not whether you reproduce a specific textbook design. If you already know CAP theorem, load balancers, caching, and sharding — the concepts this site's system design basics post covers — this is the part nobody explains clearly: how to actually run the 45 minutes so that knowledge shows up in your score.

Most rubrics score across four things: how you scope an ambiguous problem, how clearly you structure and communicate your thinking, whether you can go both broad (cover the system) and deep (defend one component under pressure), and how honestly you reason about trade-offs. A candidate who knows every buzzword — CDN, consistent hashing, sharding, eventual consistency — but wanders through the conversation without a clear structure will typically score lower than a candidate with a smaller vocabulary who runs a clean, deliberate process. That's a genuinely counterintuitive result for people who spent months reading concept material and assumed that was the whole job.

The Time Budget: What to Spend Where

There's no universal law here, but the commonly recommended split — and the one worth defaulting to — looks like this: roughly 5–8 minutes on requirements and scoping, 10–15 minutes on high-level design, 15–20 minutes on a deep dive into one or two components, and 5–10 minutes wrapping up with trade-offs. Notice where the largest block sits: the deep dive, not the high-level diagram. Interviewers commonly weight deep-dive reasoning as the single largest chunk of the score, precisely because that's where surface-level knowledge and real understanding stop looking the same.

The most common time-management failure follows directly from not knowing this: candidates spend 60% of the interview polishing the high-level box diagram — adding a CDN here, a message queue there, redrawing arrows — and either rush the deep dive into the last five minutes or never reach it at all. An interviewer watching this happen doesn't conclude you don't know about queues. They conclude you can't manage a technical conversation under time pressure, which is its own scored skill.

Treat the budget as a spoken commitment, not just a mental note. Saying “I want to spend about five minutes on requirements so we leave real time for a deep dive” out loud does two things: it keeps you honest about the clock, and it's itself a process signal interviewers read as experience. Nobody minds you glancing at the time in a system design interview — it's expected.

Phase 1: Requirements Gathering and Scoping (Don't Skip This)

Start by restating the prompt in your own words — it forces you to commit to an interpretation out loud instead of silently assuming one. Then ask 3–5 clarifying questions that actually change the shape of your design, split across three buckets: functional scope (for “design Twitter,” is search in scope? Trending topics? Direct messages? Or just posting and a home timeline?), scale (rough DAU/MAU, and critically, the read:write ratio — a 1000:1 read-heavy system and a write-heavy one lead to very different architectures), and the one or two non-functional properties that actually matter for this specific system (a payments system cares about consistency over latency; a social feed is the opposite).

The distinction that separates a strong opening from a weak one: a scope-narrowing question versus a wasted one. “What language should I use?” changes nothing about your design — skip it. “Should the home timeline be truly real-time, or is a few seconds of staleness acceptable?” changes whether you need a push-based fan-out architecture or can get away with a simpler pull-based one on read. Ask the second kind.

Close this phase by stating what's explicitly out of scope and getting a quick nod from the interviewer — “so we're not handling DMs or search today, just posting and the timeline, is that right?” This single sentence is what stops scope creep from quietly reappearing at minute 40 when there's no time left to handle it properly.

Phase 2: Back-of-Envelope Estimation, Done Fast

The point of this phase isn't the arithmetic — it's turning “a lot of users” into a concrete number that will justify a specific design decision later. “At this QPS, a single Postgres instance handles this fine, we don't need sharding yet” is a far stronger sentence than “we'll shard the database” said on reflex, with no number behind it.

Here's the actual estimation, done at interview speed, for a chat system with 50 million daily active users sending an average of 40 messages a day each:

total messages/day = 50,000,000 x 40 = 2,000,000,000
average QPS = 2,000,000,000 / 86,400 seconds ≈ 23,148
peak QPS (x3 for a typical daily peak multiplier) ≈ 69,444

storage: ~100 bytes/message (text + metadata)
daily storage = 2,000,000,000 x 100 bytes ≈ 186 GB/day
yearly storage ≈ 66 TB/year

A useful shortcut worth naming out loud: approximate a day as 100,000 seconds instead of the exact 86,400. It's about 14% off, which is completely fine for a back-of-envelope number — you're establishing an order of magnitude to justify a decision, not producing a capacity-planning report. Round aggressively, say your assumption out loud (“I'll round a day to 100,000 seconds”), and immediately connect the resulting number to a design choice. That connection — not the division itself — is what the interviewer is actually listening for.

Phase 3: High-Level Design — Boxes That Earn Their Place

Run this phase as a conversation, not a silent drawing exercise. Start from the core API contract or data flow — what does a client actually send, and what comes back — and add only the components your phase 2 numbers justify. If the QPS you just calculated is comfortably served by one database and a simple app-server tier, say so and don't add a queue or a cache you can't justify. Narrate every box as you add it, and check in once the skeleton is up: “that covers the core flow we scoped — want me to go deeper on a specific part, or is there something you'd like me to reconsider here?”

The mistake this phase punishes hardest is reaching for a fully-loaded “big tech” architecture — microservices, Kafka, Redis, a CDN, a sharded database — regardless of what the numbers from phase 2 actually called for. Interviewers read this as cargo-culting a memorized architecture rather than reasoning from constraints, and it's one of the fastest ways to undercut a strong requirements phase that came before it.

Phase 4: The Deep Dive Is Where You're Actually Evaluated

Either let the interviewer pick which component to go deep on, or proactively name the hardest part of your own design and propose diving there first — both are fine, but say your intent out loud rather than waiting passively for direction the entire interview. “The part I think is actually hard here is keeping the follower count consistent under concurrent writes — want to go there?” shows ownership in a way that silence never does.

Depth means specifics, not more boxes: actual schema and index choices, a concrete consistency guarantee and what it costs, a named failure mode and how the system degrades under it, and numbers from phase 2 applied directly to this one component. The gap between a shallow and a deep answer on the same topic is stark. Shallow: “we'll use a cache to speed up reads.” Deep: “we'll cache the hot feed reads in Redis with a five-minute TTL and write-through invalidation on new posts, because our read:write ratio from the estimation phase was roughly 20:1, so keeping reads off the primary database is worth the invalidation complexity.” Same idea, one of them earns points.

Phase 5: Wrapping Up — Trade-offs, Not a Victory Lap

A strong close names one or two real weaknesses in your own design before the interviewer has to ask “what would you do differently.” Be specific about what you gave up and why: “I chose eventual consistency for the follower count, which means a user might briefly see a stale number right after a new follow — that's the trade-off I made for the write throughput we needed at this scale.” That sentence demonstrates you understood your own design's cost, which is a different and more valuable skill than having produced the design in the first place.

The mistake here is treating the last few minutes as a finish line — going quiet, or saying some version of “I think that covers it” and waiting for the interviewer to end things. Keep demonstrating critical thinking about your own work until time is actually called. Interviewers specifically watch for whether a candidate can critique themselves, because that's a decent proxy for how they'll behave in a real design review months into the job.

Frequently Asked Questions