Purpose: This is your universal problem-solving engine. Apply these 7 steps to EVERY system design question, in this exact order. Never skip steps. Never reorder them.

---

The 7-Step Framework

Step 1 — Clarify Requirements (5–10 min)

What you do: Ask questions before drawing anything. you give your self ambiguous problems on purpose like my app own how much latency of response . and your job is to scope it

Questions to always ask:

• What is the PRIMARY use case? (e.g., read-heavy or write-heavy?)

• Who are the users? (consumers, businesses, internal?)

• What scale are we targeting? (1K users? 100M users?)

• What's the SLA? (latency requirements, uptime?)

• Do we need real-time updates or is eventual consistency okay?

• What are the most critical features for v1?

• Any geographic constraints? (global vs. single region)

• Any compliance/security requirements?

Functional Requirements = What the system DOES

Non-Functional Requirements = How WELL it does it (latency, availability, consistency, durability)

• Example — URL Shortener Requirements

  Functional:

  • User can submit a long URL and get a short URL back

  • User visits short URL and gets redirected to long URL

  • (Optional) Custom aliases, expiry dates, analytics

  Non-Functional:

  • Reads >> Writes (100:1 ratio typical)

  • Sub-100ms redirection latency

  • 99.99% availability

  • URLs should not be predictable/enumerable

---

Step 2 — Define Constraints + Assumptions (5 min)

What you do: Lock in the numbers and boundaries. This stops scope creep and makes your design focused.

Questions to ask:

• How many daily active users (DAU)?

• Read/write ratio?

• How long should data be retained?

• Budget constraints? (do we optimize for cost or performance?)

• Team size constraints? (affects complexity you can build)

Output: A written constraint list. Example: "We assume 100M DAU, 10:1 read/write, data retained 5 years, 99.9% uptime required."

---

Step 3 — Do Rough Estimation (5–10 min)

What you do: Back-of-envelope math to understand the scale of the problem. This determines WHICH components you'll need.

Estimation Template:

Metric	Formula	Example (URL Shortener)
QPS (writes)	DAU × write_actions / 86400	100M × 1 / 86400 ≈ 1,200 QPS
QPS (reads)	write_QPS × read_ratio	1,200 × 100 = 120,000 QPS
Storage / day	QPS × record_size × 86400	1,200 × 500B × 86400 ≈ 50 GB/day
Storage / year	daily × 365	50GB × 365 ≈ 18 TB/year
Bandwidth (in)	write_QPS × record_size	1,200 × 500B = 600 KB/s
Bandwidth (out)	read_QPS × record_size	120K × 500B = 60 MB/s

Key insight from estimation: If reads >> writes → you need caching. If storage > 10TB → you need sharding. If QPS > 10K → you need load balancing.

---

Step 4 — High-Level Design (10–15 min)

What you do: Draw the major components and how data flows between them. Think in boxes and arrows.

Standard HLD Components to consider:

• Client (mobile/web)

• Load Balancer

• API Gateway

• Application Servers

• Database (primary/replica)

• Cache layer

• CDN (for static content)

• Message Queue (for async work)

• Storage (blob/object store)

The 3 questions for every component you add:

1. Why does this component exist here?

2. What happens if it fails?

3. What's the data flow through it?

---

Step 5 — Deep Dive Into Components (10–15 min)

What you do: Pick 2–3 components the problem cares most about. Go deep on those.

What 'deep dive' means:

• Database schema design (not just 'use a database')

• Specific indexing strategy

• Cache key design and eviction policy

• API endpoint contracts

• Data model for the core entity

• Sharding key choice and why

Anti-pattern: Trying to go deep on everything. You'll run out of time and show you can't prioritize.

---

Step 6 — Identify Bottlenecks (5 min)

What you do: Stress-test your own design. Ask: where does this break?

Bottleneck checklist:

• [ ] Single point of failure? (anything without redundancy)

• [ ] Hot spots in the database? (popular URLs, viral posts)

• [ ] Network bottleneck? (large payloads, many hops)

• [ ] Write bottleneck? (high write QPS to single DB)

• [ ] Read bottleneck? (cache miss storms)

• [ ] Latency cliff? (synchronous chains that add up)

---

Step 7 — Optimize + Scale (5–10 min)

What you do: Address the bottlenecks you found. Propose solutions with explicit trade-offs.

Optimization toolkit:

• Horizontal scaling (add more servers)

• Database sharding (split data by key)

• Read replicas (scale reads separately)

• Caching layer (reduce DB load)

• Async processing via queues (decouple slow work)

• CDN (move static content closer to users)

• Rate limiting (protect from abuse)

For each optimization say: "I'm adding X to solve Y bottleneck. The trade-off is Z (complexity/cost/consistency)."

---

💻 Framework in Practice — Mental Model

PROBLEM ARRIVES
    ↓
Step 1: What are we building? (scope)
    ↓
Step 2: What are our constraints? (lock numbers)
    ↓
Step 3: What scale demands does this create? (math)
    ↓
Step 4: What boxes + arrows satisfy the requirements? (HLD)
    ↓
Step 5: How does the hardest part actually work? (LLD)
    ↓
Step 6: Where does this break under load? (stress test)
    ↓
Step 7: How do we fix those breaks? (optimize + scale)

---

⚠️ Common Framework Mistakes

Mistake	Why It's Wrong	Fix
Jumping to components immediately	You'll design the wrong thing	Always do Step 1–2 first
Skipping estimation	You won't know if you need cache/sharding	Always do the math
Going too deep on one component	Misses the full picture	Time-box each step
Never mentioning trade-offs	Shows shallow thinking	Force yourself: after every decision say 'the trade-off is...'
Designing only the happy path	Real systems fail	Always ask 'what happens when X fails?'