HLD vs LLD

System design interviews and real projects both operate at two altitudes.

HLD — High-Level Design

The big-picture architecture of a system:

• Main modules and their responsibilities
• Overall request/data flow
• How components interact (sync vs async, which protocols)
• Technology choices at the boundaries (DB type, queue, cache, CDN)

Deliverable: an architecture diagram you can defend — boxes, arrows, and the reasoning for each. Questions like “design Twitter” or “design a URL shortener” are HLD exercises. The scaling toolkit lives here: load balancers, sharding, caching, queues (see the other fundamentals notes).

LLD — Low-Level Design

The detailed design of each module from the HLD:

• Classes, interfaces, and their relationships
• Function signatures and API contracts
• Database tables/schemas and indexes
• Implementation logic and edge cases

Deliverable: code-shaped artifacts — class diagrams, schemas, API specs. Questions like “design a parking lot” or “design a BookMyShow seat-booking flow” are LLD exercises; they test object-oriented design and data modeling rather than scale.

How They Relate

	HLD	LLD
Question answered	What are the pieces and how do they talk?	How is each piece built inside?
Audience	Architects, senior engineers, interviewers	Implementing engineers
Output	Architecture diagram + component choices	Class/API/schema design
Failure mode if skipped	Building detailed the wrong thing	Vague hand-waving that collapses in code review

Rule of thumb: HLD first to make the big bets cheap to change, LLD second to make each bet buildable. A strong answer names the HLD components, then drills into LLD for the one or two most interesting components rather than shallowly covering everything.

---

Part of the System Design Fundamentals series.