Two different zoom levels
The clearest way to tell high-level design (HLD) and low-level design (LLD) apart is to think of
them as the same system viewed at two different zoom levels.
High-level design asks: what are the major components of this system, and how do they
communicate? A high-level design for a ride-sharing app might involve a matching service, a
pricing service, a notifications service, a database, and a message queue between them. The
deliverable is usually a box-and-arrow diagram of services, data stores and the network calls
between them.
Low-level design asks: inside one of those boxes, what are the actual classes? A low-level
design for the same app's matching service might involve a Driver class, a RideRequest
class, a MatchingStrategy interface, and the methods that connect them. The deliverable is
class-level structure — attributes, methods, interfaces and relationships — that someone could
implement directly.
Side-by-side comparison
| High-Level Design | Low-Level Design | |
|---|---|---|
| Unit of design | Services, components, data stores | Classes, interfaces, methods |
| Typical concerns | Scalability, availability, network calls, storage choice | Responsibilities, relationships, extensibility of the object model |
| Typical output | A component diagram | A class diagram or the classes themselves |
| Example question | "Design a URL shortener" | "Design a parking lot system" |
Both formats deal with trade-offs and ambiguity — the difference is the unit being designed,
not the presence of judgement calls.
Where the line blurs
Some prompts genuinely span both — "design a parking lot system" is usually treated as an LLD
problem, but a version of it with multiple locations, real-time availability across a city, and
a backend API starts to pull in HLD concerns too. Don't worry about drawing a hard line; focus
on answering the level of question that was actually asked.
Why interviews test them separately
A candidate can be strong at one and weaker at the other — they draw on different instincts.
Someone can design a beautifully scalable set of services that talk over a queue, and still write
a God class with fifteen responsibilities inside any one of them. Conversely, someone can design
a pristine, well-factored class hierarchy that would fall over the moment two services need to
talk to each other reliably.
Testing them as separate rounds lets an interview panel assess both instincts independently,
rather than one masking a weakness in the other.
Key takeaways
Key takeaways
- HLD designs the system as a set of communicating components; LLD designs the objects inside one of those components.
- The two skills don't guarantee each other — interviews test them separately on purpose.
- When a prompt is ambiguous about which level is expected, ask — don't assume.
Further reading
Further reading
- Requirement Analysis for LLD Interviews — Next: , for a repeatable way to scope an LLD prompt before designing a single class.