Free lesson · Low Level Design Fundamentals
LLD vs HLD
LLD vs HLD
High-Level Design (HLD) and Low-Level Design (LLD) are two altitudes of the same activity - designing software - separated by what they decide. HLD is the macro view: which services exist, how they communicate, what databases and queues and caches sit where, how the system scales and stays available. LLD is the micro view: inside one service or component, which classes exist, what each is responsible for, and how they collaborate. The intent of distinguishing them is to know, at any moment, which set of questions you're answering - because the vocabulary, the diagrams, and the trade-offs are different at each level.
This topic follows the definition of LLD (1.1) and sharpens it by contrast. The rest of this course operates almost entirely at the LLD level, but the boundary matters constantly: many cross-cutting topics later (API design in Module 38, persistence in Module 30, resilience in Module 33) sit right at the seam where LLD meets HLD, and knowing which side you're on keeps design discussions coherent.
In interviews, conflating the two levels is one of the most common ways to lose the thread. An LLD interview that drifts into "I'd put a load balancer in front of three instances" has changed altitude and stopped answering the question. Being able to state crisply "that's an HLD concern; at the LLD level the relevant decision is…" is a strong signal of design maturity.
The Problem It Solves
The same prompt can be answered at the wrong altitude:
Prompt: "Design a ride-hailing feature."
HLD answer (macro): rider service, driver service, matching service,
Kafka for location events, Redis for geo-index,
Postgres for trips, autoscaling, regional sharding...
LLD answer (micro): Rider, Driver, Trip, MatchingStrategy, Location classes;
how Trip transitions through states; how the matcher
selects a driver; interfaces and responsibilities...
Neither is wrong in general - but only one answers the question being asked. Spending an LLD interview on Kafka and sharding, or an HLD interview on class hierarchies, means solving a different problem than the one posed. The distinction exists so you can deliberately pick the altitude the situation demands.
The Two Altitudes Side by Side
graph TD
subgraph HLD[High-Level Design - macro]
H1[Services & boundaries]
H2[Databases, caches, queues]
H3[Scalability, availability, sharding]
H4[Network & protocols between systems]
end
subgraph LLD[Low-Level Design - micro]
L1[Classes, interfaces, methods]
L2[Responsibilities & relationships]
L3[Design principles & patterns]
L4[Object interactions within a service]
end
HLD -.zoom into one service.-> LLD
style LLD fill:#1e1b4b,color:#fff
A comparison of the two design altitudes. High-level design is the macro view: it decides services and their boundaries, databases, caches and queues, scalability and availability concerns like sharding, and the network and protocols between systems. Low-level design is the micro view: it decides classes, interfaces and methods, the responsibilities and relationships among them, which design principles and patterns to apply, and how objects interact within a single service. Zooming into any one service from the high-level diagram lands you in low-level design territory.
The relationship is one of zoom. HLD draws the system as services and infrastructure; pick any one service and zoom in, and you're now doing LLD - designing that service's internal classes. They share concerns at the seam: an API contract (Module 38) is an HLD-visible boundary realized by LLD classes; a database choice is HLD, but the Repository and persistence design (Module 30) that talks to it is LLD.
What Differs, Concretely
The artifacts differ: HLD uses deployment and component diagrams; LLD uses class and sequence diagrams (Module 13). The trade-offs differ: HLD weighs latency vs consistency vs cost across machines; LLD weighs cohesion vs coupling, flexibility vs simplicity within a codebase (Module 39). The failure of each differs: bad HLD shows up as systems that can't scale or stay available; bad LLD shows up as code that can't be changed or tested. They're complementary - a beautifully architected system can still rot at the class level, and elegantly designed classes can't rescue a fundamentally wrong topology.
Interactive animation: Artifacts, trade-offs and failures side by side: bad HLD cannot scale or stay available, bad LLD cannot be changed or tested.
Why This Matters in Interviews
Interviews are usually explicitly one or the other, and the first move is to confirm which. In an LLD round, signalling that you know the boundary - "I'll keep this at the class-design level; the service topology and data-store choice I'd treat as HLD" - keeps you on target and shows range. When an LLD problem touches the seam (it needs an API, or persistence), handling it at the LLD altitude (the interface, the Repository) while acknowledging the HLD context is exactly the calibrated answer interviewers reward.
Common Mistakes
- Wrong altitude for the round. Giving an infra/topology answer in an LLD interview, or a class-diagram answer in an HLD interview.
- Never confirming which. Not clarifying the expected level and guessing wrong for the whole session.
- Ignoring the seam. Treating API contracts or persistence as purely one level when they bridge both.
- Believing one subsumes the other. Assuming good architecture guarantees good code (or vice versa); they're independent qualities.
Try It
Take a system you know and write two short designs for it: an HLD (services, stores, how they talk) and an LLD for one of those services (its key classes and their responsibilities). Notice how the vocabulary and diagrams change between them, and find the seam - the API or data boundary where your HLD hands off to your LLD. Being able to move deliberately between the two altitudes, and to state which one a question is asking about, is the framing skill this topic builds.