HLD Interview Framework

45 Minute Ka Fixed Structure

💡 HLD interview SHEHAR KA MASTER PLAN banane jaisa hai. Tumse ye nahi poocha ja raha ki ek ghar ki deewar kaise banegi — poocha ja raha hai ki paani, bijli, sadak aur sewage kahan se aayenge aur 10 lakh log aane par kya tootega.

Har achha HLD round EK HI structure follow karta hai: REQUIREMENTS (functional + non-functional), SCALE ESTIMATION (QPS, storage, bandwidth), API DESIGN, DATA MODEL, HIGH LEVEL ARCHITECTURE, aur phir DEEP DIVE + BOTTLENECKS. Ye 6 steps ratna kaafi hai — har problem inhi par chalti hai.

Sabse badi galti hai turant boxes banana shuru kar dena. Pehle non-functional requirements pin karo — kitne users, read-heavy hai ya write-heavy, latency kitni chahiye, consistency kitni zaroori hai. Inhi jawaabon se architecture nikalta hai; inke bina har design "sahi" bhi hai aur "galat" bhi.

// Har HLD problem ka same skeleton:

// 1. Functional requirements     -> system KYA karega (3-5 core features)
// 2. Non-functional              -> scale, latency, availability, consistency
// 3. Scale estimation            -> DAU -> QPS -> storage -> bandwidth
// 4. API design                  -> 3-4 core endpoints
// 5. Data model                  -> entities + kaunsa DB aur KYU
// 6. Architecture                -> client -> LB -> service -> cache -> DB
// 7. Deep dive                   -> bottleneck pakdo aur fix karo

🧭

HLD interview SHEHAR KA MASTER PLAN banane jaisa hai. Tumse ye nahi poocha ja raha ki ek ghar ki deewar kaise banegi — poocha ja raha hai ki paani, bijli, sadak aur sewage kahan se aayenge aur 10 lakh log aane par kya tootega.

1 / 2

⚡ Quick Recap

6 steps: requirements → scale → API → data model → architecture → deep dive
Non-functional requirements hi architecture decide karte hain, features nahi
Turant boxes banana sabse badi galti hai

Is page mein (2 subtopics)

FUNCTIONAL requirements batate hain ki system KYA karega — "user video upload kar sakta hai", "user feed dekh sakta hai". Inhe 3-5 core features tak seemit rakho, warna 45 minute mein kuch bhi complete nahi hoga.

NON-FUNCTIONAL requirements batate hain ki system KAISA hoga — scale, latency, availability, consistency, durability. YAHI architecture decide karte hain. "10 lakh users" aur "10 crore users" ke liye bilkul alag design banta hai, chaahe features same hon.

💡Tip: Scope explicitly kaato — "main abhi upload aur playback par focus kar raha hoon, comments aur monetization out of scope maan raha hoon." Interviewer isse khush hota hai, kyunki wo dekhna chahta hai ki tum prioritize kar sakte ho.

CAP kehta hai ki network partition ke waqt tumhe Consistency ya Availability mein se ek chunna padega. Galti ye hai ki log "hum AP system banayenge" bolkar chhod dete hain — poore system ke liye ek choice nahi hoti.

Sahi tareeka hai PER-FEATURE choose karna. Payment ledger = CP (paisa galat nahi ho sakta, thoda downtime chalega). Social media likes = AP (thoda purana count chalega, par service kabhi down nahi honi chahiye). Ek hi system mein dono ho sakte hain.

💡Tip: "Is feature ke liye main consistency chunoonga, us feature ke liye availability" — ye ek line CAP ki asli samajh dikhati hai, ratta nahi.

Next →🔢 Back of the Envelope Estimation

Code10x

HLD Interview Framework

Functional vs Non-Functional Requirements

CAP Theorem Ko Sahi Se Use Karna