The 45-Minute HLD Framework: How to Ace Any System Design Interview
A battle-tested, minute-by-minute framework for structuring your system design answer — from requirements gathering to trade-off discussion — used by engineers who've cracked FAANG and unicorn interviews.
After reading: You'll have a repeatable 45-minute structure you can apply to any system design question — no more blanking out.
Most engineers who fail system design interviews don't fail because they don't know the material. They fail because they don't have a structure for the 45 minutes they've been given.
They jump to components too early. They spend 20 minutes on requirements and run out of time for the design. They forget to mention trade-offs. They answer a different question than the one being asked.
This framework solves all of that. It's a minute-by-minute structure that works for any HLD question at any company.
Why Most People Fail HLD Rounds
🔑
Key point
The interviewer is watching how you think, not just what answer you arrive at. Two candidates can produce identical designs — one gets the offer, one doesn't — because one showed clear, structured reasoning and the other arrived at the same place via happy accident.
The 45-Minute Clock
Here's the exact time allocation you should use. Stick to it — and tell the interviewer where you are in the process.
Signal time awareness out loud: "I'm going to spend the next 5 minutes on requirements, then move to the high-level design." This shows the interviewer you're in control of the conversation, not reacting to it.
Step 1: Requirements (0–5 min)
This is the most important step. Get it wrong and everything downstream is wrong.
Functional requirements (what the system does):
State the 3–5 user-facing operations. Be explicit. "Users can create short URLs. Anyone can redirect from a short URL to the original. Users can see click analytics."
Non-functional requirements (how the system behaves):
This is where you earn points. Ask about scale, latency, availability, consistency.
The 5 questions you should always ask:
"What's the expected scale — DAU, QPS?"
"What's the latency SLA for the critical path?"
"Is this read-heavy or write-heavy?"
"Do we need strong consistency, or is eventual consistency OK?"
"Any specific constraints I should design around?"
💡
Tip
If the interviewer says "assume any scale you like" — that's a trap. Pick a real, defensible scale: "I'll design for 10M DAU and 1000 writes/sec." This forces you to make real architectural decisions instead of hand-waving.
Non-negotiable non-functionals for common problem types:
Messaging systems → At-least-once delivery, idempotency, ordering guarantees
Payment systems → ACID, exactly-once processing, no data loss
Search systems → Sub-100ms latency, freshness of index
Social feeds → Read-heavy, eventual consistency OK, P99 < 500ms
KnowEase.AI
Practice the framework on real HLD questions
Understanding the 45-min structure is step one. Executing it under time pressure is step two. KnowEase gives you AI-graded HLD practice with per-dimension feedback — so you know exactly where you're losing points.
Conclusion: read-heavy, needs CDN/cache, consider NoSQL for key-value lookups
What capacity estimation tells you:
QPS > 10K → you need horizontal scaling (multiple app servers behind LB)
Storage > 1TB/year → you need distributed storage or object store
Read:write > 10:1 → aggressive caching is necessary
Sub-100ms latency → in-memory cache is mandatory
Step 3: High-Level Design (10–25 min)
Now draw the system. Start simple. Add only the components you can justify.
The standard template (start here, adapt as needed):
Client → CDN (if media-heavy)
→ Load Balancer
→ Application Servers (stateless, horizontally scaled)
→ Cache (Redis) — for hot reads
→ Primary DB (Postgres/MySQL/DynamoDB)
→ Message Queue (Kafka) — for async processing
→ Background Workers
The 3 rules for the HLD phase:
Every component you draw, you must be able to justify. Don't add a Kafka if you can't explain why a direct DB write isn't sufficient.
Name the API endpoints — at least the 2–3 most critical ones. This shows you've thought about the interface.
State the data model — at a minimum: the primary entities and their key fields. Schema design signals maturity.
ℹ️
Note
You don't need to draw a perfect diagram — even a rough verbal description works. "I'd have a stateless API tier behind a load balancer, writing to a Postgres primary with a Redis cache in front for frequently accessed data" is a valid high-level design.
API design checklist:
Use REST or gRPC (state which and why)
Include auth: Authorization: Bearer <token> on every endpoint
Specify the request and response schema for the 2 most critical endpoints
Mention pagination for list endpoints
Step 4: Deep Dive (25–40 min)
This is where you pick 2–3 of the hardest or most interesting components and go deep.
How to pick what to deep dive:
What's the hardest part of this system to get right?
What's the highest-risk component (if this fails, everything fails)?
What did you hand-wave in the HLD that deserves more thought?
Common deep dives by problem type:
For URL Shortener: Key generation (Base62 vs hash vs counter — trade-offs of each)
For Food Delivery: Driver matching algorithm (geohash, nearest available, distributed lock)
For Twitter Feed: Fanout strategy (write-time vs read-time vs hybrid for celebrities)
For Payment System: Idempotency key design and the state machine
For Notification System: Queue design, deduplication window, DLQ retry logic
🔑
Key point
The deep dive is where senior candidates separate themselves. A junior candidate stays at the box-and-arrow level throughout. A senior candidate picks one component and shows they understand its internals: data structures, failure modes, edge cases, operational concerns.
Example deep dive — driver matching in food delivery:
"The hardest part of this system is matching delivery partners to orders within 2 seconds. I'd use Redis Geo to store the real-time location of all online drivers. When an order comes in, I run a GEORADIUS query to find all available drivers within 3km. I then run a simple scoring function — distance weighted 60%, acceptance rate weighted 30%, current load 10%. The top-scoring driver gets a push notification. I use a distributed lock (Redis SETNX with 10s TTL) to prevent the same driver from being assigned two orders simultaneously. If the driver doesn't accept within 30 seconds, I release the lock and pick the next candidate."
That answer demonstrates: data structure choice, query design, scoring logic, concurrency handling, and timeout handling. That's what a deep dive looks like.
Step 5: Trade-offs (40–45 min)
Never end without discussing trade-offs. If the interviewer cuts you off before you get here, still bring it up: "Can I take 2 minutes to discuss the key trade-offs in this design?"
The trade-off formula:"I chose X over Y because [reason specific to this system's requirements]. The downside is [cost]. I'd mitigate this by [mitigation], and I'd revisit this decision if [condition]."
Trade-offs that always matter:
SQL vs NoSQL — consistency and query flexibility vs scale and schema flexibility
Monolith vs microservices — simplicity and latency vs team autonomy and independent scaling
Synchronous vs asynchronous — latency vs throughput and resilience
Strong vs eventual consistency — correctness vs availability and performance
Cache invalidation strategy — TTL (simple, stale) vs write-through (consistent, expensive) vs cache aside (flexible, complex)
Common Mistakes to Avoid
"I would use microservices" — without saying which services, why they're separate, and how they communicate
Ignoring the database schema — your data model matters; hand-waving it signals shallow thinking
No mention of failure modes — what happens when the DB is down? When the cache is cold?
Consistency of terminology — call it "the order service" consistently, not sometimes "order" and sometimes "booking"
Not asking the interviewer for feedback — after the HLD, ask: "Does this high-level design make sense? Any concerns before I go deeper?" This catches misalignments early.
Practice With AI Grading
The gap between understanding this framework and executing it under pressure in a live interview is larger than most people expect. The only way to close that gap is to practice writing full answers and getting scored.
KnowEase gives you 15 HLD questions with detailed rubrics across the 6 dimensions: scalability, data modeling, consistency, caching, trade-offs, and reliability. Each answer you write gets AI-graded feedback showing exactly where you lost points.
KnowEase.AI gives you AI-graded HLD practice, structured learning checks with dimension scoring, and a personalised roadmap. Start free — no credit card needed.