AlgoInsight

Free lesson · System Design Crash Course

The Discipline of HLD: What It Is, What It Isn't

Easy10 min readsystem-designhlddistributed-systems

Lesson 1.1 - The Discipline of HLD: What It Is, What It Isn't

The opening lesson.

Let me start with a question. Imagine your friend, who's a really good programmer, just got an offer from a big tech company. Excited, they tell you about the interview process: there was a coding round (they nailed it), a behavioral round (they handled it), and something called "system design" where they had to design Instagram on a whiteboard in 45 minutes. Your friend says: "Honestly, I didn't really know what they wanted. I just kept drawing boxes and they kept asking weird questions." They got the offer anyway, but they're not sure why.

What your friend stumbled into is High-Level Design, or HLD. And the reason they didn't really know what was happening is that almost nobody teaches this clearly. It's a real discipline - a specific way of thinking about software systems - and once you see it, you can't unsee it. But until then, it can feel like the interviewer is checking some mysterious quality that has no clear name.

This lesson is about giving HLD a clear name. By the end, you'll know what HLD is, what makes it different from other engineering activities, and why senior engineers spend so much time on it. We won't get into specific technologies yet. This is the conceptual foundation.

A Working Definition

Let me give you the cleanest definition I can:

High-Level Design is the activity of deciding the overall shape of a software system before you build it.

That's the whole thing. It's a planning activity. It happens before code gets written (or, for an existing system, before changes get made). It produces decisions about what the major pieces of the system are, how they connect, and how they handle the things that will inevitably go wrong.

The word "high-level" is doing real work here. It means we're not deciding which exact line of code goes where. We're deciding the bigger questions: how many services should this system have? Where does the data live? How do users connect to it? What happens when one part fails? We're working at the level of components and connections, not classes and functions.

If this still feels abstract, let me give you an analogy that will carry us through the whole course.

The Building Analogy

Think about building a house. There are a few different activities involved:

An architect designs the house. They decide how many rooms there are, where they go, how big they are, where the doors connect. They draw blueprints showing the overall layout. They don't decide what color you'll paint each wall, or which exact light fixtures you'll install, or which brand of refrigerator to buy. Those are smaller decisions for later.

A structural engineer makes sure the house won't fall down. They check whether the foundation can support the weight, whether the beams are strong enough, what happens during an earthquake. They think about failure.

A general contractor builds the house following the architect's plans. They hire workers, schedule materials, and turn the blueprints into reality.

An interior designer decorates the house once it's built. They pick colors, furniture, finishes.

flowchart LR
    A["Architect<br/>(Designs the house)"]
    B["Structural Engineer<br/>(Makes sure it stands)"]
    C["Contractor<br/>(Builds it)"]
    D["Interior Designer<br/>(Decorates it)"]

    A --> B
    B --> C
    C --> D

    style A fill:#a78bfa,stroke:#8b5cf6,color:#000
    style B fill:#fbbf24,stroke:#f59e0b,color:#000
    style C fill:#34d399,stroke:#10b981,color:#000
    style D fill:#fb7185,stroke:#f43f5e,color:#000

Software has the same kinds of roles. HLD is most like the architect's job. It's about the overall layout - where rooms are, how they connect, how big they need to be. The other activities (coding the components, testing them, deploying them) come later. HLD is upstream of all of them.

When senior engineers do HLD, they're thinking about:

You don't need to know yet what all of these mean in software terms. The point is just: HLD is the planning activity that decides the overall shape, before the building begins.

What HLD Is NOT

To sharpen the definition, let me name some things that are NOT HLD but get confused with it:

HLD is not writing code. When you sit down to write a function, that's coding. When you decide which functions to write before you write them, that's design. HLD is even higher than that - it's about which whole components and services to write, not which functions within them.

HLD is not designing the user interface. UI/UX design is a totally different activity. It's about what the user sees and clicks. HLD is about what's behind the screen - the servers and databases that respond to those clicks.

HLD is not low-level optimization. Deciding whether to use a hash map or a tree in a specific function is implementation work. HLD is at a higher level - deciding things like "should this data live in a cache or a database?"

HLD is not picking specific technologies upfront for their own sake. "We're using Kubernetes!" isn't HLD. HLD is the reasoning that might lead you to use Kubernetes (or not). The choice of specific technologies is the consequence of HLD thinking, not the goal.

HLD is not a one-time activity. People sometimes think you do HLD once at the start of a project and then build. In reality, you do HLD whenever a major change is being considered. Big new feature? Some HLD. Big scaling problem? Some HLD. Migrating off an old database? Definitely HLD.

What HLD Actually Produces

When someone "does HLD," what do they have to show for it? A few things:

Diagrams. Boxes and arrows showing the major components and how they connect. These are sometimes very rough (a whiteboard photo) and sometimes very polished (a formal architecture diagram). Either way, the diagram is a thinking tool - drawing it forces you to be specific about what's connected to what.

Decisions. "We'll use a SQL database for the main data, and Redis for the session cache." "We'll have a separate service for payments." "We'll put a load balancer in front of the application servers." Each of these is a decision; the collection of them is the design.

Trade-off explanations. Senior engineers don't just make decisions - they explain why. "We chose Postgres because we need transactions; we considered MongoDB but the consistency model didn't fit our use case." This is the most important part. The reasoning is often more valuable than the conclusion.

Capacity estimates. Rough numbers about how big the system needs to be. "We expect 10,000 concurrent users; that's about 50K requests per second peak." "The database will hold about 5 TB of data after one year." These numbers don't have to be exact - they're sanity checks that influence other decisions.

Failure analyses. What can go wrong, and what happens if it does. "If the cache goes down, every request hits the database. Database can handle that load? Yes, with some latency increase." "If a server dies, the load balancer will route around it; users see no impact."

How HLD Differs from "Architecture" as a Term

People use "architecture" to mean a lot of things, and the word is genuinely fuzzy. In software, the term often includes:

"HLD" is narrower. HLD is the technical design part - the boxes and arrows and decisions about components. It's a subset of "architecture" in the broader sense.

When someone says they're "doing architecture," they might mean any of the above. When someone says they're "doing HLD," they specifically mean the technical design work. The vocabulary varies by company and team, but the distinction is real.

For this course, we use "HLD" because it's specific. When we say HLD, we mean: designing the technical components of a system at a level above code but below specific implementation details.

Interactive animation: Architecture is the broad word - stack, principles, teams, culture - and HLD is its technical design slice.

When Do You Actually Do HLD?

There are five common situations where HLD work happens:

1. Starting a new project or feature. Before writing code for something significant, someone - usually a senior engineer - sketches out the design. What are the components? How do they connect? This often produces a "design document" that the team reviews.

2. Scaling an existing system. Your app is doing fine. Then traffic doubles. Then it doubles again. Now the database is slow, the servers are pegged, users are seeing errors. Time for some HLD work - figure out what's overloaded, what to change, what new components might help.

3. Major migrations. Moving from Heroku to AWS. Splitting a monolith into services. Replacing one database with another. All of these need HLD thinking. You can't just start migrating without a plan.

4. Debugging deep performance problems. When the latency is bad and you don't know why, HLD-level analysis helps. "Let me draw the request path and figure out where time is being spent."

5. System design interviews. At most senior engineering interviews, you'll be asked to design something on a whiteboard - Instagram, Uber, a chat app - in 45 minutes. This is HLD as a performance art. The skills are the same as real HLD; the constraint is time.

A Beginner's First HLD Experience

Let me give you a tiny example. Suppose your friend asks you to design a system for a school's lunch order app. Students place orders by 10 AM; the cafeteria prepares them by lunch. What do you say?

If you're brand new to HLD, you might immediately think about code: "I'll use Python with a Flask backend. Maybe a SQLite database." That's not wrong, but it's skipping HLD.

HLD would think bigger first. What are the major pieces?

  1. A web app or mobile app where students place orders.
  2. A server that receives the orders and stores them.
  3. A database where orders are kept.
  4. A view for the cafeteria showing today's orders.

That's already an HLD. Now we can think about it:

These questions are HLD questions. They don't have anything to do with Flask or SQLite. They're about the shape of the system and how it handles its job. The technology choices follow from these answers.

This isn't a complicated example. But the activity - thinking through components, asking what can go wrong, sizing things - is the activity. Scale this up to designing Instagram or Stripe, and you have system design at the level a senior engineer practices it.

Interactive animation: A first HLD for school lunch orders: four boxes, then questions like 500 orders a day and downtime at 9:55.

Why HLD Matters for Your Career

Two reasons, honestly:

One: it's the difference between a junior engineer and a senior one. Junior engineers implement what they're told. Senior engineers design what gets built. The transition between these levels - at most companies - comes when you can credibly do HLD. Without HLD skills, you'll always be the person who codes someone else's design.

Two: it's tested everywhere. Every senior engineering interview at every major tech company includes a system design round. If you can't do HLD, you can't pass these interviews, no matter how good your coding skills are.

Both of these are practical. HLD isn't just an academic discipline - it's a core skill that affects your career trajectory in concrete ways.

What's Coming in This Course

This course will teach you HLD systematically. By the end:

That's a tall order. We'll get there step by step. This module is the orientation; the next 30 modules are the substance.

Interactive animation: The practice portals interview you back: you answer, they score you, and they say what to fix next.

Six Takeaways from This Lesson

  1. HLD is the activity of deciding the overall shape of a software system before building it. Higher than code, lower than philosophy.

  2. The architect-of-a-house analogy is the right mental picture. You're deciding rooms and connections, not paint colors and furniture.

  3. HLD is not coding, UI design, low-level optimization, or technology picking. It's the planning that informs all those.

  4. HLD produces diagrams, decisions, trade-offs, capacity estimates, and failure analyses. All five matter.

  5. "Architecture" is broader than HLD; it includes principles, technology stack, and organizational context. HLD is the technical design part.

  6. HLD is a career skill. Senior engineers are expected to do it. Interviews test it. It's the gate between mid-level and senior.

Try It

Exercise: Warmup (10 minutes). Pick a software product you use daily (Instagram, Slack, Uber, whatever). Without doing any research, sketch a quick HLD on paper. What components do you think it has? You'll probably get half of it wrong - that's fine. The exercise is the value.

Exercise: Core (20 minutes). Find a published architecture diagram for a real company's product. Search "Netflix architecture" or "Stripe engineering blog" - pick whatever interests you. Compare your sketch from the warmup to what the real engineers describe.

Exercise: Stretch (30 minutes). Pick the school lunch-order example from earlier and write a brief HLD for it. What components? What technology choices? What can go wrong? Don't worry about being right - focus on practicing the activity.

What's Next

Lesson 1.2 clarifies the difference between HLD, LLD, design docs, and "architecture." These terms get confused all the time, and getting them straight is worth a lesson on its own.

Back to System Design Crash Course