13. Structured walkthrough — speak in sequence, not in circles¶

~15 min read. A strong design can still fail if your explanation feels like a traffic jam.

Built on the ELI5 in 00-eli5.md. The menu — what users can ask from the system — becomes your opening move, because you cannot design the restaurant before clarifying the order.

1) First picture: the interview has a natural order¶

See. Good candidates do not start with Kafka, Redis, or sharding. They move in four passes.

┌────────┐   ┌──────────┐   ┌────────┐   ┌──────────┐
│ scope  │──→│ estimate │──→│ design │──→│ deep dive│
└────────┘   └──────────┘   └────────┘   └──────────┘

Scope means users, features, and the house rules.
Estimate means traffic, storage, and peak load.
Design means the core boxes and data flow.
Deep dive means one or two hard tradeoffs.

Look. This order helps the interviewer follow your thinking. It also protects you from overengineering. If the menu is tiny, the system may stay simple. If the house rules are strict, you know where to spend complexity. Simple, no?

A useful opening line is: "Let me clarify scope first, estimate scale second, propose a baseline design third, and then go deep on the hardest tradeoffs." That sentence alone creates confidence.

2) Time management in 45 minutes: do not spend 30 minutes clarifying¶

Now what is the problem? Many candidates know enough design. They lose by misusing time.

A good 45-minute split is:

5 minutes for scope and requirements
7 minutes for back-of-envelope estimates
18 minutes for the baseline design
10 minutes for one deep dive
5 minutes for recap and tradeoffs

Total:

5 + 7 + 18 + 10 + 5 = 45 minutes

Worked example. Suppose the interviewer says, "Design a photo-sharing system." You might estimate like this.

20 million daily active users
2 photo uploads per user per day
uploads per day = 20,000,000 × 2 = 40,000,000
average upload rate = 40,000,000 ÷ 86,400 ≈ 463 uploads per second
peak factor = 4×
peak upload rate ≈ 463 × 4 = 1,852 per second

For reads:

15 feed opens per user per day
feed reads per day = 20,000,000 × 15 = 300,000,000
average read rate = 300,000,000 ÷ 86,400 ≈ 3,472 per second
peak read rate ≈ 3,472 × 4 = 13,888 per second

For storage:

average photo size = 2 MB
daily storage = 40,000,000 × 2 MB = 80,000,000 MB
80,000,000 MB ≈ 80 TB per day

See. In under 2 minutes, you already know the shape. Reads dominate writes. Blob storage matters. CDN matters. Metadata and feed fan-out matter.

So what to do? Do only enough math to guide architecture. Not a census.

3) Communicate tradeoffs in one clean sentence¶

Look. Interviewers do not only want boxes. They want judgment. The easiest format is:

I chose X because Y.
The cost is Z.
If constraint C changes, I would revisit.

Examples.

"I chose cache-aside because reads dominate 20:1. The cost is stale reads during invalidation. If freshness becomes critical, I would revisit write-through or versioned reads."
"I chose asynchronous fan-out because write latency matters more than instant follower updates. The cost is temporary lag in some timelines. If premium users require immediate delivery, I would add a fast path."
"I chose a monolith first because the team is small and boundaries are still moving. The cost is weaker isolation. If deploy frequency or ownership pain rises, I would split the hottest domains later."

Simple, no? State the win. State the cost. State the condition for change. That sounds senior.

One more trick. When two options are both valid, compare them on the active constraint. Latency? Cost? Consistency? Team size? Regulatory risk? Never compare in the abstract.

4) Handling pushback, depth control, and the whiteboard¶

See. Pushback is not punishment. It is the interviewer asking, "Can you adapt?"

A good response pattern is:

acknowledge the concern,
restate the assumption,
branch the design,
choose one path and continue.

Example. The interviewer says, "What if cache invalidation becomes messy?" A calm answer is: "Yes, that is the main cost of this choice. If freshness is strict, I would reduce cache scope and rely more on direct reads for that entity. For now, because reads are heavy and some staleness is acceptable, I still prefer the cache."

That is much better than panic. It shows control.

Now depth. Do not go deep everywhere. Go deep where one of these is true:

highest scale,
highest risk,
highest ambiguity,
or strongest interviewer interest.

If the interviewer keeps asking about a topic, that is a gift. Go there. If they do not, keep the design moving.

A clean whiteboard layout helps.

┌──────────────────────────────────────────────┐
│ top    : scope + assumptions + key numbers  │
├──────────────────────────────────────────────┤
│ left   : write path                          │
│ right  : read path                           │
├──────────────────────────────────────────────┤
│ bottom : bottlenecks, tradeoffs, deep dive  │
└──────────────────────────────────────────────┘

Look. Do not scatter boxes randomly. Reserve space for the deep dive. Label arrows. Name data stores. Mark optional components lightly. The interviewer should understand your board from two meters away.

5) Common anti-patterns, and how to recover fast¶

Now what is the failure mode in interviews? Not ignorance. Often it is chaos.

Common anti-patterns:

jumping to a solution before clarifying requirements,
overengineering for imaginary scale,
spending 10 minutes on one schema detail,
hiding assumptions instead of saying them,
never summarizing the tradeoff.

Suppose you catch yourself rambling. Reset immediately. Say this: "Let me tighten the structure. The scope is X. The key load is Y. I will draw the minimum viable design first, then go deep on Z."

That one sentence can save the interview.

Another recovery trick. If the interviewer asks for something you skipped, do not defend the omission emotionally. Just slot it in. "Good catch. I treated that as optional earlier. Let me add it and show how it changes the read path."

The restaurant metaphor helps here too. Do not redesign the building when the question was about the menu. Do not discuss napkin color when the house rules are about uptime. Keep the answer at the right altitude.

A senior walkthrough feels calm. It is structured. It has visible assumptions. It knows when to stop. Yes?

Where this lives in the wild¶

Uber dispatch architecture review — a staff engineer opens with scope, traffic, and failure constraints before proposing a matcher change.
Stripe ledger migration review — a principal engineer states, "I chose dual writes for migration speed; the cost is reconciliation complexity," instead of pretending the path is free.
YouTube upload pipeline interview loop — a senior candidate separates ingest, processing, storage, and playback on the board instead of mixing every component together.
Amazon retail search design review — an engineering manager pushes back on cache invalidation, and the presenter handles it by naming the assumption and branching the design cleanly.
LinkedIn feed candidate loop — a candidate spends the deep-dive time on fan-out versus pull, not on every secondary table detail.

Pause and recall¶

What are the four stages of a strong system design walkthrough?
Why is a 45-minute time split useful even before the interview starts?
What is the best sentence pattern for communicating a tradeoff?
How do you decide whether to go deeper or stay broad?

Interview Q&A¶

Q: Why start with scope, not with the architecture you already know? A: Because architecture only makes sense relative to the product ask and the non-functional constraints. Without scope, even a beautiful design may solve the wrong problem.

Common wrong answer to avoid: "Starting with architecture saves time" — it often wastes time by forcing later rework when requirements change.

Q: Why do estimates before boxes, not after? A: Because scale tells you which components deserve attention. Traffic and storage numbers decide whether you need CDN, sharding, queues, or something much simpler.

Common wrong answer to avoid: "Estimates are optional if you know common patterns" — patterns without scale awareness become cargo cult design.

Q: Why deep dive on one hotspot, not every subsystem equally? A: Because the interview measures prioritization as much as coverage. Going deep everywhere usually means going deep nowhere.

Common wrong answer to avoid: "More detail always looks stronger" — uncontrolled detail often signals weak judgment, not strength.

Q: Why state the cost of your choice, not present the design as perfect? A: Because real senior design is about tradeoffs. Naming the downside shows you understand the decision boundary and can adapt if the constraint changes.

Common wrong answer to avoid: "Confidence means defending one answer hard" — rigid certainty often sounds less senior than explicit tradeoff awareness.

Apply now (5 min)¶

Pick one common interview problem. Write your first five clarifying questions. Then write a 45-minute split for scope, estimate, design, deep dive, and recap. Finally, write one tradeoff sentence using the format, "I chose X because Y. The cost is Z."

Sketch from memory:

the 4-step framework,
the whiteboard layout,
and the recovery sentence for when you start rambling.

Bridge. You can present the design. But every design has edges you're unsure about. Honesty about limits is a signal of seniority, not weakness. → 14-honest-admission.md