Chapter 1: What HLD and LLD Are, and How They Differ

Why this matters

"High-level design" and "low-level design" are used constantly in interviews and design reviews, but the actual boundary between them — and why that boundary matters practically, not just terminologically — is often fuzzy even for experienced engineers. Getting this distinction precise is what lets you correctly scope a design document, correctly staff a design review (who needs to be in the room for which level), and correctly recognize when a document mislabeled as one is actually doing the job of the other.

The core distinction

[BEGINNER] High-level design (HLD) answers "what are the major pieces of this system, and how do they fit together?" — it operates at the level of components, services, data flow between them, and major technology choices, deliberately without specifying implementation details within any single component. Low-level design (LLD) answers "within a specific component, exactly how is this built?" — class structures, database schemas, API contracts, method-level logic. The companion System Design book's Chapter 2 building-blocks diagram is squarely HLD territory; a specific class's method signatures and a specific table's exact columns are squarely LLD territory.

HLD question: "Should the notification system be a separate service
              communicating via a message queue, or a module within
              the main application?"

LLD question: "Within the notification service, what does the
              NotificationTemplate class's interface look like, and
              what database schema stores delivery status?"

Why the boundary matters practically, not just terminologically

[SENIOR INSIGHT] The practical payoff of distinguishing these precisely: they require different reviewers, different levels of stakeholder involvement, and different amounts of flexibility to change later. An HLD decision (should this be a separate service?) affects every team that will ever interact with this system and is expensive to reverse once other components are built assuming it — it deserves broad, cross-team review (companion SDLC book, Chapter 5). An LLD decision (what should this one class's internal method be named?) affects primarily the engineers actually implementing that component and is comparatively cheap to change later — it doesn't need the same broad review, and requiring it would waste organizational attention on a decision that doesn't warrant it.

Mismatch to avoid: convening a cross-team architecture review to debate
                    a single class's private method naming (LLD-scoped
                    decision, wrong audience, wasted organizational time).

Mismatch to avoid: one engineer unilaterally deciding, with no broader
                    review, that a new system should be a separate
                    service requiring its own database and deployment
                    pipeline (HLD-scoped decision, insufficient review
                    for something this consequential and hard to reverse).

Where HLD and LLD sit in the broader lifecycle

[BEGINNER] Directly building on the companion SDLC book's Chapter 5: requirements gathering (this book's Chapter 2) determines what needs to be built; HLD determines the major how at the architecture level; LLD determines the specific how within each component; implementation then follows the LLD's plan. This ordering isn't rigid or strictly one-directional in practice (Chapter 7 covers the realistic, iterative relationship between HLD and LLD), but the general flow — coarser decisions before finer ones — is the reason this ordering exists at all: an LLD decision made before the relevant HLD decision risks being invalidated entirely if the HLD later changes, wasting the more detailed design effort.

Common mistakes

1. Producing an HLD that's actually full of LLD-level detail (specific class method signatures) or an LLD that's actually still at HLD-level vagueness (no concrete schema or API contract) — mislabeling the document's actual scope confuses reviewers about what they're being asked to evaluate.
2. Convening the wrong audience for a given decision's actual scope — a cross-team review for an LLD-scoped decision wastes organizational attention; unilateral, unreviewed decision-making for an HLD-scoped decision skips genuinely necessary broader input.
3. Treating HLD and LLD as a strictly one-way, one-time sequence, missing that LLD work frequently reveals a gap or flaw in the HLD that requires revisiting it (Chapter 7 covers this in depth).
4. Assuming every project needs the same amount of HLD and LLD rigor, rather than calibrating to the decision's actual stakes and reversibility — directly the companion SDLC book's Chapter 5 "match design rigor to context" principle.

Checklist: applying the HLD/LLD distinction correctly

1. Ask "does this decision affect the major components/architecture, or the internals of one component?" to correctly classify a given design question as HLD or LLD scoped.
2. Match the review audience to the decision's actual scope — broad, cross-team review for HLD-scoped decisions; narrower, component-team review for LLD-scoped ones.
3. Sequence HLD before LLD for a given piece of work, but stay willing to revisit HLD when LLD work reveals a genuine gap (Chapter 7).
4. Calibrate the rigor of both HLD and LLD to the decision's actual stakes and reversibility, not uniformly across every project regardless of context.

Discussion / interview questions

1. "What's the difference between HLD and LLD, and why does the distinction matter practically?" Strong answer: HLD covers major components, their responsibilities, and how they interact; LLD covers the specific implementation details within a component (classes, schemas, API contracts) — the distinction matters because each requires a different reviewer audience and carries a different cost of being wrong/needing to change later.

2. "Why might convening a large, cross-team design review for a purely LLD-scoped decision be a mistake?" Strong answer: An LLD-scoped decision (like a single class's internal structure) primarily affects the engineers implementing that specific component and is comparatively cheap to change later — a broad review wastes organizational attention that should be reserved for decisions with wider impact and higher cost of being wrong.

3. "Should LLD always be done strictly after HLD is fully finalized?" Strong answer: Generally HLD should come first since it shapes the context LLD operates within, but the relationship isn't strictly one-directional — LLD work can reveal a gap or flaw in the HLD that genuinely requires revisiting it, and a mature process accommodates this rather than treating the initial HLD as immutable once LLD begins.

4. "How would you decide how much HLD and LLD rigor a specific project needs?" Strong answer: Calibrate to the decision's actual stakes and reversibility — a small, low-risk, easily-reversible component needs much less formal HLD/LLD documentation than a major, hard-to-reverse architectural decision or a component many other systems will depend on.

Chapter summary / cheat sheet

• HLD: major components, responsibilities, interactions, technology choices — the "what pieces, how do they fit." LLD: specific implementation details within a component — classes, schemas, API contracts, method-level logic — the "exactly how is this built."
• The distinction matters practically because each requires a different reviewer audience and carries a different cost of being wrong or needing to change.
• HLD generally precedes LLD, but the relationship is realistically iterative — LLD work can reveal HLD gaps worth revisiting (Chapter 7).
• Calibrate rigor at both levels to the decision's actual stakes and reversibility, not uniformly across every project.

---