SYSTEM DESIGN:Lesson 4: System Design Interview Framework

Mastering lesson 4: system design interview framework concepts and implementation.

What you need from this lesson

A system design interview is 45 minutes. You get an open prompt (“design Swiggy,” “design a URL shortener”). The interviewer watches how you think — not whether you name every buzzword.

You will learn a 4-step loop you can reuse every time:

Clarify the product (do not draw yet)
Put rough numbers on the board
Draw a simple architecture, then deepen one part
Call out trade-offs and what you would do next

Drawing boxes in minute two is a bold strategy

Minute-by-minute map

Four-step system design interview framework

Minutes	Do this	Stop if…
0–8	Ask scope questions	You are already drawing boxes
8–15	Estimate QPS / storage	You skip numbers entirely
15–35	High-level design + 1 deep dive	You add 12 microservices with no reason
35–45	Trade-offs, failures, “what next”	You freeze or start a new design from scratch

Step 1 — Understand the problem (5–8 min)

Do not touch the whiteboard yet. Ask questions until the problem is small enough to finish.

Ask about	Example
Users & scale	“How many DAU? India-only or global?”
Top features	“What are the 3 must-haves? What is out of scope?”
Read vs write	“Read-heavy, write-heavy, or mixed?”
Latency	“Real-time, or is a few seconds OK?”
Consistency	“Can data be slightly stale?”
Retention	“Keep data forever or for N days?”

Example — “Design a food delivery app like Swiggy”:

You: "Customer ordering only, or also restaurant + rider apps?"
Interview: "Customer: browse, order, track."

You: "Scale?"
Interview: "10M DAU, Indian cities."

You: "Tracking — live GPS stream, or refresh every 30s?"
Interview: "30s refresh is fine."

You: "I will cover browse → cart → place order → status.
      I will skip restaurant admin and rider routing."

Narrowing scope is a feature, not a weakness.

Step 2 — Estimate scale (5–7 min)

Use the estimation lesson. Write numbers on the board before you invent components.

DAU: 10 million
Orders/user/day: 0.5  →  5M orders/day
Browse: 3 sessions × 20 requests → 600M browse req/day

Total ≈ 605M / day
Avg QPS ≈ 605M ÷ 100K ≈ 6,000
Peak (lunch/dinner, 5×) ≈ 30,000

Later you can say: “CDN for restaurant photos because a big chunk of that 30K peak QPS is images.” Numbers justify boxes.

Step 3 — High-level design (15–20 min)

Draw in this order. Add a box only when the numbers need it.

1. Client
2. Load balancer
3. Stateless API servers
4. Database (+ read replicas if reads are high)
5. Cache (Redis) for hot reads
6. CDN for images / static
7. Queue for async work (notifications, receipts)
8. Extra services only if the prompt needs them

Swiggy-shaped sketch:

Mobile → LB → API servers
              ├─ Redis (menus, session)
              ├─ Postgres (orders, users)
              ├─ CDN (photos)
              └─ Queue → notification workers

Then pick one deep dive (10 min), for example:

How place-order works end to end (API → DB → queue)
How browse stays fast (cache keys, TTL, invalidation)
What happens if the payment service is down

Depth on one path beats a shallow map of twenty services.

Step 4 — Trade-offs and wrap-up (5–10 min)

Leave time to talk about what breaks and what you would build next.

Topic	What to say
Single point of failure	“Primary DB — I’d add replicas / failover.”
Hot key	“One viral restaurant — cache + rate limit.”
Consistency	“Order status can lag 30s; payment cannot.”
Next iteration	“Shard orders by city, add search service.”

End with: “If we had another hour, I’d deepen X.” That shows judgment.

What interviewers punish

Habit	Why it hurts
Drawing in minute 1	You designed the wrong product
Buzzword salad	Kafka/microservices with no traffic reason
No numbers	Cannot justify cache, shards, or CDN
Never saying “I don’t know”	Fake certainty loses trust
Ignoring the interviewer	They steer you — follow the steer

Practice plan (1 week)

Day 1–2: Run the 4 steps on URL shortener (out loud, timer on)
Day 3–4: Same for a feed or chat prompt
Day 5: Mock with a friend — they only ask clarifying questions
Day 6–7: Redo weak step (usually estimation or deep dive)

Use scaling basics and data layer when you need the “why” behind a box.

Checklist (print or save)

[ ] Scope in 3 bullets before drawing
[ ] DAU → QPS (avg + peak) on the board
[ ] Read:write called out
[ ] Client → LB → API → DB drawn first
[ ] Cache / CDN / queue only with a reason
[ ] One deep dive, not five
[ ] One failure mode + one “next step”