# System Design Thinking Framework — 7-Step Engine

> **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

```plaintext
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?' |