What is LLD?

The Gap It Fills

A team receives an HLD: “Order Service calls Payment Service, backed by Postgres.” The first developer opens the IDE and invents fifteen classes ad hoc. Three weeks later, adding UPI payments touches eleven files because payment logic leaked into orders, notifications, and the controller. Nobody designed the inside of the boxes — that inside design is Low-Level Design.

LLD converts one component of an HLD into a class-level blueprint: concrete classes, interfaces, fields, exact method signatures, relationships, state transitions, and invariants — enough detail that implementation requires zero further design decisions.

Position in the Stack

Requirements ────► HLD ──────────► LLD ─────────► Code
  WHAT              HOW (macro)     HOW (micro)
 features          services        classes
 scale targets     storage choice  method contracts
 SLAs              queues, caches  relationships
                                   invariants

Read left to right, each stage answers a narrower question. HLD decides which services exist and how they talk; LLD decides what’s inside one service. A mistake at the HLD stage costs a migration; a mistake at the LLD stage costs a refactor. Both stages exist because mixing the two questions produces neither a scalable system nor readable code.

Scope Boundaries

In Scope (LLD)	Out of Scope (HLD territory)
Class & interface identification	Service topology
Fields + exact method signatures	Database engine selection
Relationships & multiplicities	Load balancing, sharding
Design pattern application	Capacity estimation
Concurrency within one process	Cross-service consistency
Error model of a component	API gateway design

The boundary blurs in practice — a monolith team’s “HLD” may be another team’s “LLD.” What matters is decision granularity, not document names.

Standard Interview Format (35–45 min)

• 0–5 min: Requirements clarification — lock functional core + constraints.
• 5–20 min: Entities, relationships, class diagram.
• 20–35 min: Core slice implemented in code (Java/C++/Python).
• 35–45 min: Follow-ups — new feature, concurrency, scale twist.
• Canonical problems: Parking Lot, Elevator, BookMyShow, Splitwise, Vending Machine, Chess, LRU Cache, single-node Rate Limiter.

Rubric Axes

Axis	Junior signal	Senior signal
Modeling	Classes mirror nouns	Responsibilities assigned; verbs become methods on owners
Extensibility	Works for stated case	Survives the unstated follow-up
Patterns	Stuffs patterns	Deletes unneeded patterns; justifies each
State	Public fields, setters everywhere	Invariants enforced at construction and mutation
Concurrency	Ignored until asked	Names shared mutable state unprompted

Failure Modes

• Coding at minute 5: solves the wrong problem completely and elegantly.
• God class (ParkingLotManager owning tickets, slots, pricing, payments): fails every extensibility follow-up.
• Anemic domain: XService classes hold all logic; entities are field bags — interviewer reads it as no OO depth.

The Problem It Addresses

Software decays even when nobody touches requirements. Month one: feature ships in a day. Month twelve: the same-sized feature takes a sprint and breaks two unrelated flows. Nothing changed except accumulated accidental structure — classes entangled through shortcuts taken when “there was no time to design.” Maintenance consumes 60–80% of total software lifecycle cost (Boehm’s cost model, replicated across industry studies), and code is read roughly 10× more often than written — so design quality is primarily a read-time property.

Cost to add feature N+1
 ▲                              ╱ no deliberate design:
 │                          ╱╱   every change touches
 │                      ╱╱        everything (tangles grow)
 │                 ╱╱───────────── deliberate design:
 │           ╱╱╱                    bounded blast radius,
 │      ╱╱╱                         new code plugs into seams
 └──────────────────────────────────────► time / feature count

The curves are illustrative, not measured benchmarks — but the divergence mechanism is mechanical: each undisciplined change adds edges to the dependency graph, and edit cost tracks edges touched.

The Six Goals

Goal	Definition	Mechanism that delivers it
Correctness	Valid states only	Invariants enforced at construction + mutation points
Extensibility	Add features without editing core	Program to interfaces; Open-Closed
Maintainability	Change one thing, break nothing	High cohesion, low coupling
Testability	Unit-test without infrastructure	Dependency injection creating seams
Reusability	One implementation, many callers	Composition over inheritance
Communication	Diagram = enforceable team contract	UML class/sequence diagrams

No design maximizes all six simultaneously — an interface for everything buys extensibility at the cost of simplicity. Deliberate LLD is choosing which goals this component needs.

Defect Economics

Fix cost grows roughly an order of magnitude per phase (requirements → design → code → production): a flaw caught in design review costs minutes; the identical flaw reaching production costs an incident plus rollback. LLD review is the cheapest place defects ever get caught.

Why Interviews Test It

• LLD performance predicts daily-job refactoring ability far better than memorized patterns do.
• It resists cramming: a follow-up (“now support multiple floors”) instantly exposes copied designs.
• It tests vocabulary precision — a candidate who says “use a factory here” but cannot name what varies fails the bar.

What Good Looks Like

• Every class answers: what state do I own, which invariants must hold, which requests can I serve?
• Adding a feature means adding classes/methods, not editing existing ones (Open-Closed in practice).
• No class exceeds a few hundred lines before responsibilities leak — beyond that cohesion is gone.

Failure Modes

• Pattern stuffing: Strategy + Factory + Builder for a three-class problem — indirection must earn its cost.
• Premature generality: interfaces with exactly one implementation and no test-seam purpose — YAGNI noise for reviewers.
• Design amnesia: clean whiteboard diagram, code diverges from it immediately — reviewers check they agree.