Acing the system design interview: a 45 minute playbook

The system design interview isn't a test of whether you can build Twitter in 45 minutes. Nobody can. It's a test of how you reason about tradeoffs under ambiguity. Once you understand what's being graded, the panic drops and a repeatable structure takes over.

Here's the playbook, mapped to the clock.

Minutes 0 to 7: pin down the problem

Never start drawing. The fastest way to fail is to architect the wrong system confidently. Spend the first stretch turning a vague prompt into concrete requirements.

• Functional requirements — what must it actually do? Pick the two or three core flows and explicitly defer the rest.
• Non-functional requirements — scale, latency, availability, consistency. "Design a URL shortener" for 100 users and for 100 million users are different systems.
• Back-of-envelope numbers — daily writes, read-to-write ratio, storage growth. These numbers drive every later decision.

State your assumptions out loud and get a nod before moving on. Interviewers steer here; let them.

Minutes 7 to 15: the high-level sketch

Draw the boxes that move data. Resist details. A clean spine looks like this:

Walk the interviewer through one request end to end. This proves the design is coherent before you zoom into any single piece.

Minutes 15 to 30: go deep where it counts

This is where senior signal lives. Pick the component that carries the real difficulty and interrogate it.

• Data model — what are the tables or documents? What's the access pattern? Model around how data is read, not how it's neatly normalized.
• The bottleneck — every interesting system has one. A feed has fan-out. A rate limiter has shared counters under contention. Name it and design for it.
• Storage choice — SQL for relationships and transactions, NoSQL for scale and flexible schemas. Justify it; don't cargo-cult.

If you've practiced a rate limiter hands-on, you already know the sliding-window-versus-token-bucket tradeoff cold — that concrete depth is exactly what separates candidates.

Minutes 30 to 40: scale and protect it

Now stress the design. Walk through how it survives growth and failure.

• Caching — what's read-heavy? Cache it, and have an answer for invalidation.
• Sharding and replication — how does the database split as data grows? What's your shard key?
• Failure modes — what happens when a node dies, the queue backs up, or traffic spikes 10x? Single points of failure are interview kryptonite.
• Bottleneck math — revisit your minute-0 numbers and show the design holds.

Minutes 40 to 45: close strong

Summarize the design in three sentences, then name what you'd revisit with more time. "With another hour I'd harden the consistency model on the write path" signals maturity. You're showing you know the design is a draft, not a monument.

What graders actually reward

• Structured thinking over memorized architectures.
• Explicit tradeoffs — every choice has a cost, and you should say it.
• Driving the conversation while staying responsive to hints.
• Knowing when good enough beats perfect.

The candidates who freeze are the ones treating this as a recall test. The ones who shine treat it as a guided design session where they happen to be holding the marker.

Build the reps

This structure only feels natural after repetition. Drill the building blocks in the System Design lessons, and sharpen the algorithmic depth that backs them — problems like merge intervals train the interval and scheduling reasoning that shows up in real designs. A full progression sits in the roadmaps, and you can measure where you stand on the leaderboard.

Head into Cruxible, get matched against an AI judge at your tier, and design under real pressure before the real interview does it for you. Can you still beat the machine?