Chapter 13: A Repeatable Framework for Any System Design Problem

Why this matters

Every chapter in Parts 1-3 covered one piece of the system design toolkit. This chapter assembles them into a single, repeatable, five-step process — usable for genuinely any system design prompt, in an interview or in real project planning — and Chapters 14-17 apply this exact framework, step by step, to four different worked examples, so the framework's generality is demonstrated concretely rather than just asserted.

The five-step framework

[BEGINNER]

1. CLARIFY REQUIREMENTS (Chapter 3)
   Functional: what must the system actually do?
   Non-functional: scale, latency, availability, consistency, read/write ratio.

2. ESTIMATE SCALE (Chapter 4)
   Convert requirements into concrete numbers: requests/second (average
   and peak), storage growth, bandwidth -- establishing the right order
   of magnitude for every subsequent decision.

3. SKETCH A HIGH-LEVEL DESIGN (Chapter 2's building blocks)
   Draw the major components and how requests flow through them --
   client, load balancer, service(s), cache, database, queue -- at a
   level that could be redrawn from a verbal description alone.

4. DEEP-DIVE THE HARDEST COMPONENT
   Identify which single part of the design is genuinely the hardest,
   most interesting, or most failure-prone problem, and go deep
   specifically there -- this is where the real trade-off reasoning
   (Chapters 5-12) actually happens; spreading equal shallow attention
   across every component wastes the opportunity to demonstrate depth
   where it matters most.

5. DISCUSS TRADE-OFFS AND FAILURE MODES
   Explicitly name what was NOT chosen and why, what would break under
   higher scale than estimated, and how the design handles the failure
   of its own components (Chapter 12).

Why step 4 (deep-diving) is the step most candidates under-invest in

[SENIOR INSIGHT] A very common, real mistake: spending roughly equal time on every component of a high-level design, producing a broad-but-shallow answer that never demonstrates genuine depth anywhere. The strongest answers explicitly identify which component is the hardest or most interesting before diving in ("I think the trickiest part of this design is going to be X, so let me focus there") — this single move signals that the reasoning behind step 3's high-level design was deliberate, not just a rote recitation of standard building blocks, and it uses the available time where it actually demonstrates the most genuine skill.

Weak approach: spend 5 minutes on load balancing, 5 minutes on caching,
               5 minutes on the database, 5 minutes on the API design --
               equal, shallow treatment of everything, running out of
               time before reaching genuine depth anywhere.

Strong approach: spend 5 minutes on the high-level sketch (step 3, covering
                 all the standard building blocks briefly), then explicitly
                 say "the hardest part of this design is going to be X" and
                 spend the REMAINING time going deep specifically there.

Time allocation as a practical, learnable skill

[IN PRACTICE] In a time-boxed interview context specifically, a reasonable rough allocation: roughly 15% clarifying requirements, 10% estimation, 20% high-level sketch, 40% deep-dive, 15% trade-offs/failure modes — these aren't rigid percentages, but the shape (clarify and estimate quickly, sketch efficiently, then spend the plurality of remaining time on genuine depth) is the practically learnable skill, and it's exactly what distinguishes a well-paced 45-minute answer from one that either rushes past requirements entirely or never reaches genuine depth because too much time was spent perfecting the initial sketch.

Adapting the framework to a real project, not just an interview

[BEGINNER] The same five steps apply directly to real project planning, just without the compressed time-box: requirements gathering (companion SDLC book, Chapter 4) and estimation happen over days or weeks rather than minutes; the high-level design becomes an actual design document (companion SDLC book, Chapter 5) reviewed by stakeholders; the "deep dive" happens as detailed low-level design specifically for the hardest, highest-risk component; and trade-offs get documented as an ADR (companion SDLC book, Chapter 8) rather than spoken aloud to an interviewer. The framework doesn't change — only the time scale and the artifacts produced at each step do.

Common mistakes

1. Skipping straight to a high-level design without clarifying requirements or estimating scale first — exactly Chapter 3's warning about proposing architecture before understanding what it actually needs to satisfy.
2. Spending equal, shallow time on every component rather than explicitly identifying and deep-diving the hardest one — this is the single most common reason an otherwise-competent design conversation fails to demonstrate real depth.
3. Never explicitly discussing trade-offs or failure modes, leaving a design that sounds complete but hasn't actually been stress-tested even verbally against "what if this specific part fails" or "what if scale is 10x higher than estimated."
4. Treating the framework as interview-only, missing that the identical five steps apply directly, just at a different time scale and with different artifacts, to real project planning.

Checklist: applying the five-step framework

1. Always clarify requirements and estimate scale before sketching any architecture — this order is not optional or reversible.
2. Sketch the high-level design efficiently, using precise vocabulary (Chapter 2) rather than spending disproportionate time perfecting the initial sketch.
3. Explicitly identify the hardest component before diving into any single one, and allocate the plurality of remaining time/effort there.
4. Always close by discussing trade-offs and failure modes explicitly — what wasn't chosen and why, and what happens when a component fails.

Discussion / interview questions

1. "Walk me through your general approach to any system design problem." Strong answer: Produces the five-step framework (clarify requirements, estimate scale, sketch high-level design, deep-dive the hardest component, discuss trade-offs/failure modes) and explains why the order matters — especially clarifying and estimating before designing, and deep-diving deliberately rather than spreading shallow attention everywhere.

2. "Why is explicitly identifying 'the hardest part of this design' before diving in a stronger approach than covering every component equally?" Strong answer: Equal, shallow coverage of every component never demonstrates genuine depth anywhere and risks running out of time before reaching it; explicitly identifying the hardest component signals deliberate reasoning behind the high-level design and focuses remaining time where it can actually showcase real trade-off skill.

3. "How would this five-step framework change if you were doing system design for a real project rather than an interview?" Strong answer: The same five steps apply, but at a different time scale (days/weeks instead of minutes) and producing different artifacts (a design document, an ADR, detailed low-level design for the highest-risk component) rather than a spoken, time-boxed answer — the underlying reasoning process is identical.

4. "What would you do if, partway through a system design interview, you realized your initial high-level sketch had a flaw?" Strong answer: Acknowledge it explicitly and adjust the design, treating it as the trade-off discussion step arriving earlier than planned — a candidate willing to revise an earlier decision when a flaw becomes apparent demonstrates stronger engineering judgment than one who defends a flawed design rigidly to avoid appearing inconsistent.

Chapter summary / cheat sheet

• The five-step framework: clarify requirements → estimate scale → sketch high-level design → deep-dive the hardest component → discuss trade-offs and failure modes.
• Deep-diving one deliberately-identified hardest component beats shallow, equal coverage of everything — this is where genuine trade-off reasoning skill is actually demonstrated.
• A rough time allocation (light on clarify/estimate, moderate on sketching, the plurality on deep-dive, some on trade-offs) is a practical, learnable pacing skill for time-boxed contexts.
• The same framework applies to real project planning, just at a different time scale and producing different artifacts (design docs, ADRs) instead of a spoken interview answer.

---