Picture your friend describing how she books an IRCTC ticket: she opens the app, picks a train, pays, and gets a confirmation — all in a few seconds, even during Tatkal booking when a hundred thousand other people are doing the exact same thing at the exact same second. Nobody in that story thinks about servers, databases, or networks. Your job, in an HLD interview, is to be the person who DOES think about all of that — and to explain your thinking out loud, one honest decision at a time.
What does an HLD interview actually test?
It is tempting to think an HLD interview tests whether you know the "right" architecture for a famous system — as if there is one correct diagram for "design Instagram" hidden in a textbook. That is not what is being tested. What is actually being tested is whether you can take an ambiguous, one-line prompt, ask the right questions to make it concrete, and then reason — out loud, step by step — about what breaks first and how you would fix it.
A candidate who draws a beautiful, complex architecture in silence and says nothing usually does WORSE than a candidate who draws three boxes and explains, clearly, exactly why each one is there and what would break without it. The diagram is not the answer. The reasoning that produced the diagram is the answer.
HLD vs LLD — the zoomed-out sibling
System design interviews come in two zoom levels. High-Level Design (HLD), what this course covers, asks: which services exist, which databases hold what, how does a request travel between machines across a network, and what happens when one of those machines dies? Low-Level Design (LLD) zooms into ONE of those services and asks: which classes exist inside it, and how do they call each other?
A useful way to keep them straight: HLD draws boxes labelled Load Balancer, App Server, Database. LLD draws boxes labelled OrderService, PaymentStrategy, InventoryRepository — the classes living INSIDE one of HLD's boxes. Most SDE-II+ loops test both, in separate rounds.
The five questions behind every HLD answer
Strip away the specific system name, and every strong HLD answer — for a URL shortener, a chat app, a ride-hailing service, anything — is built from the same five questions, asked in this order:
- What does it need to do? (functional requirements — the features that must exist)
- How fast, and how often? (non-functional requirements and scale — the numbers that decide everything else)
- What is the simplest thing that could possibly work? (one server, one database — always start here)
- Where does that simplest thing break first, given the numbers from question 2?
- What is the specific, named trade-off of the fix for that break?
This course is really just fourteen lessons of practising questions 3 through 5, over and over, on different pieces of a system, until it becomes automatic. Question 2 — turning words into numbers — gets its own full lesson next, because it is the single habit most candidates skip and most interviewers specifically watch for.
The simplest-system-first rule
Here is a mistake that is very easy to make and very costly: hearing "design a notification system" and immediately reaching for a message queue, three microservices, and a NoSQL database — before anyone has said how many notifications per day this system actually needs to handle. If the honest answer turns out to be "200 a day, for an internal tool," that whole architecture was solving a problem that was never asked.
The simplest-system-first rule is the fix: always start your answer with the most boring possible version — one application server, talking to one database — and say so out loud. Then use your capacity numbers to find where THAT boring system genuinely breaks, and add exactly the piece that fixes THAT specific break. Every piece of complexity in your final design should trace back to a number you estimated, not a pattern you memorised.
Common mistakes
- Jumping straight to a complex architecture before asking any clarifying questions.
- Treating "system design" as a vocabulary test — naming Kafka and Redis without explaining WHY they solve a stated problem.
- Silently drawing boxes without narrating the reasoning behind each one.
- Designing for an assumed scale instead of asking or estimating it.
- Never mentioning a trade-off — presenting every choice as a free upgrade.
Quick recap
| Concept | One-liner |
|---|---|
| What HLD tests | Your reasoning process, not a memorized diagram. |
| HLD vs LLD | HLD = boxes and machines; LLD = classes inside one box. |
| The five questions | Functional reqs → scale → simplest system → where it breaks → the trade-off of the fix. |
| Simplest-system-first | Start boring; add complexity only where the numbers demand it. |
Practice Zone
Five MCQs, then two applied questions.
What does a high-level design (HLD) interview actually test?
Asked in
Which pair correctly separates HLD from LLD?
Asked in
An interviewer says 'Design Instagram.' What is the strongest first move?
Asked in
A candidate draws Client → API Gateway → Service Mesh → 12 microservices → Kafka → Cassandra → Elasticsearch for a to-do list app with 200 users. What's the actual problem?
Asked in
Which list below is a typical HLD-level component chain (not LLD)?
Asked in
A friend designs a personal blog (maybe 50 readers/day) with: Client → CDN → API Gateway → 5 microservices → Kafka → Cassandra cluster (3 nodes) → Elasticsearch → Redis cluster. What would you tell them, and what would you actually suggest?
Asked in
Sort these into HLD or LLD: (1) 'Should the Vehicle class be an interface or an abstract class?' (2) 'Should search be its own service with its own database?' (3) 'What fields does the ParkingSpot class need?' (4) 'Should we shard the bookings table by city or by hash of booking id?'
Asked in
FAQ
Is there one 'correct' architecture for a given HLD prompt?
No — HLD questions almost always have multiple reasonable answers. What matters is that YOUR specific answer matches the stated (or estimated) requirements and that you can defend its trade-offs.
Do I need to write code in an HLD interview?
Usually not full implementations — HLD stays at the level of boxes, arrows, database schemas and API shapes. Some interviewers ask for a rough schema or API signature, but working code is what LLD rounds test.
What if I've never heard of the system being asked about?
That's fine, and common — lesson 14 gives you a repeatable framework that works on any unfamiliar prompt precisely because it doesn't depend on having seen that system before.