Chapter 17 — How to Attack ANY System Design Interview
Chapter 17 — How to Attack ANY System Design Interview
Hey everyone! Welcome to Season 5 — The Interview! 🙏
You've spent 16 chapters collecting bricks — load balancers, caches, queues, shards, consensus. Now we learn to build with them under pressure. The single biggest reason people fail system design interviews isn't lack of knowledge — it's panicking and jumping straight to boxes without a plan. This chapter gives you a repeatable 6-step framework so you're calm and structured every single time.
What we will cover:
- Why a framework beats raw knowledge
- The 6-step attack plan
- How to clarify requirements (never skip this!)
- Back-of-the-envelope estimation
- Drawing the high-level design
- Deep-diving & discussing trade-offs
- Interview Questions (meta!)
1. The Golden Rule: Don't Rush to Draw
┌─────────────────────────────────────────────────────────────┐ │ BAD candidate: hears "Design Instagram" → immediately │ │ starts drawing databases. 5 min later, lost & rambling. 😰 │ │ │ │ GOOD candidate: "Great, let me first clarify the scope │ │ and requirements..." → calm, structured, in control. 😎 │ │ │ │ System design interviews test HOW you think, not whether │ │ you memorized Instagram's architecture. │ └─────────────────────────────────────────────────────────────┘
2. The 6-Step Attack Plan (Memorize This)
┌─────────────────────────────────────────────────────────┐ │ THE FRAMEWORK — spend ~45 min like this: │ ├─────────────────────────────────────────────────────────┤ │ 1. CLARIFY requirements (~5 min) ← never skip! │ │ 2. ESTIMATE scale (napkin math)(~5 min) │ │ 3. Define APIs + data model (~5 min) │ │ 4. Draw HIGH-LEVEL design (~10 min) ← the core │ │ 5. DEEP DIVE on 1–2 components (~15 min) ← show depth │ │ 6. Discuss bottlenecks/trade-offs(~5 min) │ └─────────────────────────────────────────────────────────┘
Let's break down each step.
Step 1 — Clarify Requirements (The Most Important Step)
Never design in a vacuum. Nail down functional (features) and non-functional (scale/quality) requirements. Ask questions — interviewers want you to.
FUNCTIONAL ("what must it do?"):
"For a URL shortener — do we need custom aliases?
Analytics on clicks? Link expiry?"
NON-FUNCTIONAL ("how well?"):
"How many users? Read-heavy or write-heavy?
How important is low latency vs consistency?"
Then STATE YOUR SCOPE out loud:
"OK, I'll focus on shorten + redirect, optimize for
low-latency reads, and assume 100M new links/month.
I'll skip analytics for now." ✅
This scopes the problem so you don't drown, and shows maturity.
Step 2 — Estimate the Scale (Napkin Math)
Rough numbers decide your whole design. Read-heavy? Add caches/replicas. Huge storage? You'll need sharding. (Full method in Deep Dive 02.)
Quick example (URL shortener):
100M new links/month ≈ 40 writes/sec
Read:write ratio ~100:1 → ~4,000 reads/sec
Each URL ~500 bytes → 100M/mo × 5yr ≈ 3 TB storage
Conclusion: READ-heavy → cache aggressively + read replicas.
3TB → fits on a beefy DB, sharding optional (for now).
You don't need exact numbers — ORDERS OF MAGNITUDE guide
the design. That's the whole point.
Step 3 — APIs & Data Model
APIs (the contract):
POST /shorten { longUrl } → { shortUrl }
GET /{shortId} → 302 redirect
Data model:
urls( short_id PK, long_url, created_at, expiry )
Keep it minimal — just enough to anchor the design.
Step 4 — High-Level Design (Draw the Boxes)
Now draw the classic skeleton. Almost every design starts from this template:
[ Client ]
│
[ Load Balancer ] ← Ch 04
│
[ App Servers (stateless) ] ← Ch 02
│
┌───┴────┐
│ │
[ Cache ] [ Database ] ← Ch 06, 05
(Redis) (+ replicas Ch 07)
│
[ shards if huge Ch 08 ]
+ [ CDN ] for static (Ch 12)
+ [ Queue ] for async work (Ch 10)
Walk the interviewer through the request FLOW, step by step.
Step 5 — Deep Dive (Where You Score Points)
The interviewer picks (or you offer) one component to go deep on. This is where you prove you understand the tools from Seasons 1–4.
"Let's deep dive the short-ID generation. Options:
• random 7-char base62 → 62^7 ≈ 3.5 trillion combos
• counter + base62 encoding → guaranteed unique
• collision check on random → simple, rare retries
I'd use a counter with base62 for guaranteed uniqueness,
sharded via a range so IDs don't collide across servers..."
Show you know the TRADE-OFFS. Depth > breadth here.
Step 6 — Bottlenecks & Trade-offs
Proactively point out weaknesses (interviewers LOVE this):
"The single database is now a bottleneck — I'd add read
replicas. If writes grow, I'd shard by short_id hash.
The cache is a single point of failure — I'd cluster it.
There's a stale-cache risk on expiry — I'd set a TTL."
Naming your own weak spots = senior signal. 🌟
3. Do's and Don'ts
| ✅ DO | ❌ DON'T |
|---|---|
| Ask clarifying questions first | Jump straight to drawing |
| Think out loud constantly | Go silent for 5 minutes |
| Start simple, then scale up | Over-engineer from minute one |
| State assumptions explicitly | Assume silently in your head |
| Discuss trade-offs | Claim there's one "right" answer |
| Drive the conversation | Wait passively for hints |
Interview Questions — Quick Fire!
Q: How do you approach a system design interview?
"I follow a structured framework. First I clarify functional and non-functional requirements and scope the problem. Then I estimate the scale with rough calculations to guide decisions. Next I sketch the APIs and data model, then draw the high-level architecture and walk through the request flow. After that I deep dive into one or two components to show depth, and finally I discuss bottlenecks and trade-offs. The key is starting simple and evolving, while thinking out loud throughout."
Q: Why is clarifying requirements so important?
"Because designing without knowing the requirements leads to solving the wrong problem. Clarifying the features and the scale — how many users, read-heavy or write-heavy, latency versus consistency priorities — scopes the problem so it's manageable in 45 minutes, and it signals maturity. Interviewers deliberately leave the prompt vague to see if you'll ask."
Q: Why do a scale estimation early?
"Because the numbers drive the architecture. Knowing it's read-heavy tells me to add caching and read replicas; knowing the storage is huge tells me I'll need sharding; knowing the request rate tells me how many servers. I don't need exact figures — orders of magnitude are enough to justify design choices."
Q: What separates a strong candidate from a weak one?
"A strong candidate stays structured, thinks out loud, starts simple and evolves the design, states assumptions explicitly, and proactively discusses trade-offs and bottlenecks. A weak candidate rushes to draw components without clarifying scope, goes silent, over-engineers early, and treats the problem as having one correct answer. It's about demonstrating a clear thought process, not reciting a memorized architecture."
Key Points to Remember
| Concept | Key Takeaway |
|---|---|
| Golden rule | Don't rush to draw. They test HOW you think. |
| 6 steps | Clarify → Estimate → APIs/data → HLD → Deep dive → Trade-offs. |
| Requirements | Functional + non-functional. Scope it out loud. Never skip. |
| Estimation | Orders of magnitude guide the design (read-heavy? big storage?). |
| Score points | Deep dive with trade-offs + name your own bottlenecks. |
What's Next?
Time to use the framework for real! Chapter 18 is our first full case study: Design a URL Shortener (TinyURL) — the classic warm-up question. We'll walk all 6 steps end to end.
Keep designing, keep scaling! See you in the next one!
Post a Comment