HLD vs LLD

Why Two Layers Exist

One design layer cannot serve both questions a system raises: will this survive ten million users? and can a developer add a feature without fear? The first needs coarse boxes and resource math; the second needs classes and contracts. Mixing altitudes produces documents nobody can act on — architects debating method signatures while capacity questions go unanswered.

Zoom Levels

┌─────────────────────────────────────────────────────────┐
│ HLD view (10,000 ft)                                    │
│   ┌───────────┐   ┌────────────┐   ┌───────────────┐    │
│   │ Order Svc │──►│ Payment Svc│──►│ Inventory Svc │    │
│   └───────────┘   └─────┬──────┘   └───────────────┘    │
│        │                │                                │
│        ▼ LLD zoom on ONE box                             │
│   ┌───────────────────────────────────────────┐         │
│   │ interface PaymentProcessor                │         │
│   │ class CardProcessor  implements ..        │         │
│   │ class UpiProcessor   implements ..        │         │
│   │ enum PaymentStatus { INITIATED..CAPTURED }│         │
│   └───────────────────────────────────────────┘         │
└─────────────────────────────────────────────────────────┘

The outer frame is what HLD reviewers reason about: three services and their calls. The inset shows what LLD adds for exactly one of those boxes — types, hierarchies, states. Each service in the outer diagram gets its own inset; that multiplication is why HLD fits on one page and LLD fills dozens.

Dimension-by-Dimension

Dimension	HLD	LLD
Unit of design	Service / component	Class / interface / function
Core question	Scale, failure survival	Internal structure
Key risks	Latency, availability, cost	Coupling, invariants, thread-safety
Artifact size	10–15 pages	30–100 pages per module or full UML set
Review audience	Staff/principal engineers, architects	Senior engineer of owning team
Time horizon	Stable years; changes are events	Refactored continuously
Failure it prevents	System-wide outage	Unmaintainable codebase

The Decision-Type Split

• HLD decisions are expensive to reverse: database choice, sync-vs-async boundaries, consistency model — reversal means data migration.
• LLD decisions are cheap to reverse: rename a class, extract an interface, rewire composition — reversal is a refactor commit.
• Consequence: review effort belongs where reversal cost lives.

Boundary Blur (Real World)

• Monolith teams blur the labels; decision granularity is the real boundary.
• A shared library sits between both altitudes.
• Anti-pattern: an HLD with arrows between services but no owner named for state — that missing detail is precisely what each service’s LLD must answer.

Interview Mapping

• System Design round ≈ HLD: estimation, bottlenecks, trade-off narration.
• Machine Coding / LLD round ≈ LLD: working code, clean structure.
• Shared vocabulary only — preparing DSA + HLD while skipping machine-coding practice fails consistently at the LLD round.

Why the Artifacts Differ

Each deliverable records a decision being made at that altitude. HLD artifacts capture choices about boundaries and resources; LLD artifacts capture choices about structure and contracts. Producing the wrong set means either deciding structure before boundaries (wasted detail) or shipping code with unresolved boundary questions.

Artifact Trees

        HLD DELIVERABLES                     LLD DELIVERABLES
 ┌─────────────────────────┐         ┌──────────────────────────────┐
 │ Architecture diagram    │         │ UML class diagram            │
 │ Component/data-flow map │         │ Sequence diagrams (2–3 core  │
 │ Capacity estimates      │         │   user journeys)             │
 │ Storage schema (coarse) │         │ Interface contracts (Java)   │
 │ API surface sketch      │         │ DB schema to column level    │
 │ Tech choice + rationale │         │ State machines               │
 │ Failure-mode analysis   │         │ Error model + exceptions     │
 └─────────────────────────┘         │ Concurrency notes            │
                                     └──────────────────────────────┘

Left column answers for reviewers: will this hold at scale, and did we consider failure? Right column answers for implementers: exactly what do I build, and what must stay true?

Same Topic, Two Altitudes

Artifact	HLD version	LLD version
Diagram	Boxes = services, arrows = protocols	Boxes = classes, arrows = inheritance/association with multiplicity
Schema	orders table exists, sharded by user_id	Every column, type, index, FK, enum values
API	POST /payments exists	PaymentResult pay(PaymentRequest req) throws InsufficientFundsException
State	”Payment has states”	Full transition table incl. illegal-transition handling
Errors	Retries/timeouts at service level	Exception hierarchy per component

Interview Time Budget (40-min LLD round)

• 5 min — requirements → drives which deliverables matter.
• 10 min — class diagram (entities, relationships, multiplicities).
• 15 min — code for the core slice (interface + two implementations + entities).
• 5 min — one sequence diagram narrated verbally.
• 5 min — extensibility follow-up.

Naming a skipped deliverable explicitly (“I’d write sequence diagrams next; showing code first”) reads as prioritization. Silent omission reads as ignorance of it.

Grading Signals

• Class diagram without multiplicities (1..*, 0..1) — incomplete; expect the “can a user have zero orders?” probe next.
• Code contradicting the drawn diagram — instant credibility loss.
• Sequence diagram showing only the happy path — senior candidates show the failure path (payment declined mid-booking).

Common Mistakes

• Drawing microservice boxes in an LLD round (wrong altitude for a Parking Lot problem).
• Fifteen entity classes but zero interfaces — no seams, extensibility follow-up collapses.
• Full DB DDL for an in-memory problem — wasted minutes at the wrong layer.