Multiple-choice synthesis across the interview-framework unit: clarifying requirements and access patterns, estimation that changes the design, the HLD-and-deep-dive split, and finding the bottleneck while naming tradeoffs.
SDSenior◷ 13 min
Level
FoundationsJuniorMiddleSenior
Six questions that cut across the whole interview framework. Each is a decision you make at the whiteboard — what to ask before drawing, which number to estimate, what to deep-dive, where the bottleneck is — not a definition to recite. Answer as if the interviewer is watching for the senior signal.
Confirm you can run the framework end to end: clarify the requirement that actually changes the design, estimate only the number that matters, split a clean HLD from a real deep-dive, find the single binding bottleneck, and state a tradeoff with its price.
Quiz
Completed
Given 'design a chat app' and nothing else, which question most changes the architecture and should come first?
Heads-up Language is an implementation detail that doesn't move the high-level architecture. The non-functional target (consistency/latency) is what pushes you toward fan-out-and-cache vs strict coordination — ask it first.
Heads-up Table count is downstream of the data model, which is downstream of entities and access patterns. You can't size the schema before pinning the consistency/latency targets that shape the design.
Heads-up Cloud choice rarely changes the architecture at this stage. The load-bearing early question is the non-functional target — consistency and latency.
Quiz
Completed
A social timeline reads ~100:1 over writes. What does this access pattern most directly justify before any box is drawn?
Heads-up That optimizes the rare operation. With reads outnumbering writes 100×, you precompute and cache the read path, not speed up the infrequent writes.
Heads-up The 100:1 ratio says nothing about strict write replication, which would only slow writes. It points at optimizing reads — caching and fan-out — first.
Heads-up It's one of the most relevant facts you have: a read-heavy pattern justifies caching and precomputed reads. The access pattern, not the entity, picks the read path.
Quiz
Completed
Estimating to one significant figure: 50M DAU each make 2 posts/day, reads are ~50× posts. Which number first changes the design, and to what?
Heads-up ~1,000 writes/sec (≈3K peak) sits comfortably under a single primary's low-thousands ceiling — it does NOT force sharding yet. The design-changing number here is the ~150K peak read QPS, which forces a cache.
Heads-up Text storage may be modest, but if there's media it dominates by orders of magnitude — and regardless, the FIRST design-changing number is the ~150K peak read QPS forcing a cache/fan-out path.
Heads-up Response size is for bandwidth, computed later. Read QPS comes straight from activity ÷ seconds and already forces the cache/fan-out decision before you size bandwidth.
Quiz
Completed
You've drawn a clean five-box HLD with 30 minutes left. What is the highest-value next move?
Heads-up Breadth is table stakes and extra boxes are liabilities you must defend. The interview is won in the depth: engineer the hard component instead of inflating the HLD.
Heads-up The estimate already flagged the hard part. Re-deriving burns the budget that should go to the deep-dive — the part that proves you can engineer, not just estimate.
Heads-up That generic rattle reads as shallow and signals you've run out to say about the real problem. Go deep on the hard component; mention ops briefly at the end if at all.
Quiz
Completed
A DB cluster shows 40% average CPU, yet users hit timeouts on requests touching one popular account. What's the bottleneck, and why does the average mislead?
Heads-up The average is lying. A 40% cluster average can hide one shard at 99% (a popular account's data). The system stalls at the hottest resource regardless of the mean — that's the bottleneck the timeouts point to.
Heads-up The symptom (DB timeouts, low average DB CPU) points at uneven load inside the database — a hot shard — not the service tier. Adding service CPU widens a resource that isn't binding.
Heads-up Low average CPU with localized timeouts most directly indicates a hot shard/key skewing load, not network saturation. The lesson: the average misleads — find the single hottest resource.
Quiz
Completed
Asked 'what if traffic grows 10×?', which response shows the senior bottleneck reasoning the unit teaches?
Heads-up The mid-level reflex: true but it never names WHICH resource breaks first. The stateless tier scales out trivially; the real bottleneck moves to a stateful resource. Naming the specific binding constraint and its fix is the senior signal.
Heads-up No design scales infinitely — there's always a next bottleneck (write primary, hot shard, cache outgrowing RAM). Claiming nothing changes shows you haven't found where the constraint moves at 10×.
Heads-up Language rarely addresses the binding constraint, which at 10× is almost always a stateful resource, not service-tier CPU. The senior move is to locate that resource and fix it specifically.
Recall before you leave
01
Why is the non-functional target, not the feature list, the load-bearing early question?
02
How do you handle '10× traffic' as a procedure rather than a reflex?
Recap
The through-line is that the system-design interview is one repeatable procedure, and these six questions test each step. Clarify the non-functional target that actually changes the design (consistency/latency decides fan-out-and-cache vs coordinate), and read the access pattern (100:1 read-heavy → precomputed cached read path). Estimate only the number that matters — the ~150K peak read QPS that forces a cache, not the modest write rate or the trivia. Draw a clean HLD fast, then spend the budget on a real deep-dive of the genuinely hard component rather than inflating the box count. Find the bottleneck — the single hottest resource, which the average utilization hides (a 40% cluster melting on one shard) — and handle “10×” by recomputing, naming the new binding resource, its fix, and its tradeoff. The seniority signal under all of it: name the specific resource and the price of each choice, never just “add more servers.”
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.