Chapter 10: HLD and LLD in Design Reviews: What Reviewers Actually Look For

Why this matters

A design review meeting is only as valuable as the reviewers' ability to focus their limited time on what actually matters — and reviewers who don't have a clear mental model of what to check often default to whatever's easiest to comment on (surface-level naming, formatting of the document itself) rather than the substantive issues a design review exists to catch. This chapter closes Part 3 by covering what an effective design reviewer actually looks for, at both the HLD and LLD level.

What an HLD reviewer should focus on

[SENIOR INSIGHT] Directly building on this book's earlier chapters: an HLD reviewer's job is evaluating whether the architecture-level decisions are sound, not re-deriving the whole design from scratch or focusing on details that belong at the LLD level entirely:

## HLD review focus areas
1. Does the architecture actually satisfy the stated non-functional
   requirements (scale, availability, consistency -- Chapter 2)? Check
   the capacity estimates explicitly (Chapter 3) against the components
   chosen.
2. Are component responsibilities cleanly separated (Chapter 3's
   Single-Responsibility-at-architecture-scale check)? Flag any
   component whose responsibility needs "and" to state cleanly.
3. Are technology choices justified with explicit reasoning (Chapter 3),
   not just stated? Push back on unjustified choices specifically.
4. What are the single points of failure (companion System Design book,
   Chapter 12), and are they addressed or explicitly, deliberately accepted?
5. Does this design account for how it will evolve -- can a new
   requirement likely be added without a full redesign, without also
   over-engineering for speculative needs (Chapter 8's over-design warning)?

What an LLD reviewer should focus on

[IN PRACTICE] An LLD reviewer's job shifts to evaluating whether the implementation-level plan is correct, complete, and consistent with its HLD:

## LLD review focus areas
1. Is this LLD consistent with the HLD decisions that constrain it
   (Chapter 9's systematic contradiction-check)?
2. Are database schema constraints (Chapter 5) present for every
   real business invariant, not left to application-only validation?
3. Are API contracts complete, including error responses (Chapter 5),
   not just the happy path?
4. Is a sequence diagram present for any operation with a
   correctness-critical ordering requirement (Chapter 4)?
5. Is this LLD detailed enough to actually implement from without the
   implementer needing to invent significant, unreviewed decisions
   (Chapter 8's under-specification check)?

The reviewer's most valuable, most commonly skipped question

[SENIOR INSIGHT] Beyond any specific checklist item, the single most valuable question a design reviewer can ask, at either level, is: "what happens when this fails, or when the stated assumptions turn out to be wrong?" — directly the companion System Design book's Chapter 12 designing-for-failure discipline, applied as an active review technique rather than left to the document's author to have thought of unprompted. This question is commonly skipped specifically because reviewing the happy path (does this design accomplish its stated goal) feels more immediately productive than probing failure scenarios — but failure-mode gaps are exactly the kind of issue that's cheapest to catch in review and most expensive to discover in production.

Giving review feedback well: the same discipline as code review

[IN PRACTICE] Directly the companion Code Reviews book's Chapters 6-7: design review feedback should distinguish blocking concerns from non-blocking suggestions, be specific and depersonalized, and default to questions over commands where genuine uncertainty exists — a design review is, after all, a form of review, and the same interpersonal discipline that makes code review effective applies identically here, just one stage earlier in the lifecycle and at a coarser level of detail.

Weak design review comment: "This won't scale."
                             (vague, no specific mechanism identified,
                             not actionable)

Strong design review comment: "BLOCKING: Based on the stated peak
estimate of 8,000 req/s, a single database instance handling both
reads and writes may become a bottleneck -- have you considered read
replicas (companion System Design book, Chapter 7), or is there a
reason the estimate doesn't concern you for this specific case?"

Common mistakes

1. Focusing HLD review on surface-level document formatting or LLD-level detail, missing the actual architecture-level soundness questions an HLD review exists to evaluate.
2. Reviewing an LLD without systematically checking it against its HLD's specific constraints, relying on memory rather than Chapter 9's explicit cross-check process.
3. Never asking "what happens when this fails" during a design review, missing the single highest-leverage question for catching failure-mode gaps before they become expensive production incidents.
4. Giving vague, unlabeled, or accusatory design review feedback, rather than applying the same specific, depersonalized, blocking-vs-non-blocking discipline the companion Code Reviews book establishes for code review.

Discussion / interview questions

1. "What should a reviewer focus on when evaluating an HLD, as opposed to an LLD?" Strong answer: HLD review evaluates architecture-level soundness — does it satisfy non-functional requirements, are component responsibilities cleanly separated, are technology choices justified, are single points of failure addressed; LLD review evaluates implementation-level correctness and completeness — schema constraints, API contract completeness, consistency with the HLD, and whether the detail level is sufficient to implement from without inventing unreviewed decisions.

2. "What's the single most valuable question a design reviewer can ask, regardless of HLD or LLD level?" Strong answer: "What happens when this fails, or when a stated assumption turns out to be wrong?" — this question is commonly skipped because reviewing the happy path feels more immediately productive, but failure-mode gaps are the cheapest to catch in review and the most expensive to discover in production.

3. "How should design review feedback be structured, and why does this matter as much as it does for code review?" Strong answer: Distinguish blocking from non-blocking feedback, be specific rather than vague, stay depersonalized, and default to questions where genuine uncertainty exists — the same interpersonal discipline that makes code review effective (companion Code Reviews book, Chapters 6-7) applies identically to design review, since it's fundamentally the same kind of activity at an earlier stage.

4. "A design review comment says 'this won't scale.' What's wrong with this feedback, and how would you improve it?" Strong answer: It's vague and non-actionable — it doesn't name a specific mechanism or bottleneck; an improved version connects the concern to a specific, stated estimate and a specific architectural element ("based on the stated peak estimate, a single database instance may bottleneck — have you considered read replicas?"), giving the author something concrete to respond to or address.

Chapter summary / cheat sheet

• HLD review focuses on architecture-level soundness: non-functional requirement satisfaction, component responsibility separation, justified technology choices, single points of failure, evolvability without over-engineering.
• LLD review focuses on implementation-level correctness: HLD consistency (Chapter 9's systematic check), schema constraints, complete API contracts, sequence diagrams where needed, and sufficient detail to implement from directly.
• "What happens when this fails?" is the single most valuable, most commonly-skipped design review question at either level.
• Design review feedback should follow the same interpersonal discipline as code review (companion Code Reviews book, Chapters 6-7) — specific, depersonalized, labeled blocking vs. non-blocking.

---