System Design Explained: HLD vs LLD with Examples
By Modern AI Engineering · · 8 min read
System design is the work of deciding how a piece of software is put together before it is built. It has two levels. High-level design (HLD) decides the big parts of the system: servers, databases, caches and queues, and how requests move between them. Low-level design (LLD) opens one of those parts and decides the classes inside it and how they work together.
People often learn the two separately and never see how they connect. This article explains both, shows the difference with one example, and gives a method you can follow for each.
What is system design?
A program that runs on a laptop for one user needs little design. A product used by millions of people at once does. It has to stay fast when traffic grows, keep working when a machine fails, and stay easy to change as features are added. System design is how engineers plan for those three things.
The first two concerns, scale and failure, are mostly answered at the high level. The third, ease of change, is mostly answered at the low level.
What is high-level design (HLD)?
High-level design is the system seen from far away. Its output is an architecture diagram: boxes for components and arrows for the data that flows between them. An HLD answers four questions. What are the parts? How do they talk to each other? Where is the data stored? What happens when traffic grows or a part fails?
Take a URL shortener. Its high-level design says: browsers reach a load balancer, which spreads requests over several application servers. The servers read from a cache first and a database second. A key generator gives each server a range of ids so that two servers never produce the same short code. A queue carries click events to a worker that counts them.
What is low-level design (LLD)?
Low-level design is one component seen up close. Its output is a UML class diagram, one or two sequence diagrams, and code skeletons. An LLD answers a different set of questions. Which classes exist? What is each one responsible for? How are they related? What happens, call by call, in the main use case?
Take a parking lot. Its low-level design says: a ParkingLot owns Spots. A Spot holds at most one Vehicle. A Ticket records which vehicle took which spot and when. Fees are calculated by a PricingRule interface, so that a new pricing rule can be added without changing the ParkingLot class.
HLD vs LLD: the difference
The two are halves of one design. HLD comes first and decides the boxes. LLD comes second and designs the inside of the important ones.
| High-level design (HLD) | Low-level design (LLD) | |
|---|---|---|
| Zoom level | The whole system | Inside one service |
| Building blocks | Services, databases, caches, queues | Classes, interfaces, methods |
| Main diagram | Architecture diagram | UML class and sequence diagrams |
| Main concerns | Scale, speed, availability, cost | Clean, extensible, testable code |
| Typical interview question | Design a URL shortener, a chat app, a news feed | Design a parking lot, an LRU cache, Splitwise |
| Typical mistake | Adding components without a reason | One giant class that does everything |
How to do a high-level design, step by step
- Clarify the requirements: what the system must do, how fast and how reliable it must be, and what is out of scope.
- Estimate the scale: requests per second, the ratio of reads to writes, and storage over a few years.
- Define the API: the few calls that the outside world makes.
- Design the data model: what is stored, and which key it is looked up by.
- Draw the architecture: start with the simplest version that works, then add one component at a time, each to fix a named problem.
- Find the bottlenecks: ask what breaks at ten times the traffic and what happens when each component fails, and state the trade-off of every fix.
How to do a low-level design, step by step
- Clarify the requirements and write them as short sentences.
- Find the classes from the nouns and the methods from the verbs.
- Give each class one job and the data that job needs.
- Connect the classes, and put anything that comes in several kinds behind an interface.
- Walk the main use case through the classes with a sequence diagram, then write the code.
Where to learn both properly
The AI Engineering Bootcamp has a system design lesson on exactly this. It teaches UML class and sequence diagrams, the HLD method with a URL shortener built box by box, and the LLD method with the SOLID principles and design patterns, then solves common interview questions for each. Every diagram in that lesson is interactive: you build it one step at a time and click any box to see why it is there.
Frequently asked questions
What is the difference between HLD and LLD?
HLD describes the whole system as components such as servers, databases and caches. LLD describes the classes and methods inside one component. HLD is about scale and reliability; LLD is about clean, changeable code.
Which comes first, HLD or LLD?
HLD comes first. It decides which components exist. LLD then designs the inside of the components that matter most.
Is system design only for senior engineers?
No. Interviews for experienced roles lean on HLD, and interviews for early-career roles often include an LLD round. Learning both early makes everyday code better.
Do I need UML for system design?
For LLD, yes: a class diagram and a sequence diagram are the standard way to show a design. For HLD, a simple architecture diagram of boxes and arrows is enough.
How long does it take to learn system design?
The core ideas can be learned in a few weeks of steady study. Getting fluent takes practice on many different questions.