High-Level Design vs Low-Level Design (HLD vs LLD)

High-level design (HLD) is the architecture of a whole system: which services exist, how they communicate, where data is stored, and how it scales and fails. Low-level design (LLD) is the design of the code inside one component: its classes, interfaces, data structures and how they collaborate. Many companies interview for both as separate rounds, often called the system design round and the machine-coding or object-oriented design round, and they reward different skills.

HLD vs LLD at a glance

How an HLD round runs

1. Clarify functional and non-functional requirements.
2. Estimate scale: users, requests per second, storage. See estimation.
3. Define the main APIs. See API design.
4. Draw the high-level architecture and data flow.
5. Design the data model and choose storage. See SQL vs NoSQL.
6. Deep dive into the hardest parts: scaling, caching, consistency, failures.
7. Summarise trade-offs and what you'd improve.

The full framework is in how to prepare for a system design interview.

How an LLD round runs

1. Clarify requirements and scope: for a parking lot, which vehicle types, how many floors, how pricing works, whether multiple entry gates run concurrently.
2. Identify entities (nouns): ParkingLot, Floor, Spot, Vehicle, Ticket, Payment.
3. Define responsibilities and relationships: which class owns what, what's an interface, what's composition vs inheritance.
4. Design the key interfaces and methods, often as a class diagram.
5. Apply patterns where they fit: a strategy for pricing or spot allocation, a factory for vehicles, an observer for display boards. See design patterns.
6. Write the core code and walk through a scenario end to end.
7. Discuss extensibility and concurrency: adding a new vehicle type, two cars grabbing the same spot.

What good looks like in each

• HLD: requirements drive every component, numbers justify choices, the design is proportionate, and failure handling is explicit.
• LLD: each class has one clear responsibility, behaviour that varies sits behind interfaces, new requirements need additions not rewrites, and shared state is protected. See SOLID principles.
• Both: state assumptions, explain trade-offs, and keep it simple until a requirement demands more.

A common LLD mistake is over-engineering: ten patterns in a parking lot. Use a pattern only when you can name the change it makes easy. A common HLD mistake is the opposite of LLD's: drawing boxes without saying why each is needed.

How they connect

Real systems need both. An HLD might include a rate limiter service; the LLD of that service decides how the token-bucket algorithm, its storage interface and its configuration are structured. Senior candidates move between levels comfortably, zooming into one component's internals during an HLD deep dive when it matters.