Chapter 5: The Design Phase and Its Connection to HLD/LLD

Why this matters

The design phase is where a requirement ("users need multi-column filtering on reports") becomes an actual technical plan — and skipping or rushing this stage is one of the most common causes of implementation churn, where engineers start coding, hit an unanticipated structural problem partway through, and have to backtrack and redesign mid-implementation, at a much higher cost than if the same issue had been caught during design.

High-level design and low-level design, and where they sit in the SDLC

[BEGINNER] The companion HLD & LLD book covers this distinction in full depth; in the context of the SDLC specifically, the relationship is: requirements analysis (Chapter 4) determines what needs to be built; the design phase determines how, at two levels of granularity — high-level design (HLD) decides the major components, their responsibilities, and how they interact (which services are involved, what the data flow looks like, what technology choices are needed); low-level design (LLD) decides the specifics within a component (class structures, database schemas, API contracts, method signatures) needed to actually start implementation with a clear plan rather than figuring out the details ad hoc while writing code.

Requirements (Chapter 4)
      |
      v
High-Level Design: which services/components are involved, how do they
                    communicate, what does the overall data flow look like,
                    what are the major technology choices
      |
      v
Low-Level Design: within each component, what are the specific classes,
                   database tables, API request/response shapes, and
                   method-level logic needed to actually implement it
      |
      v
Implementation (Chapter 6)

Why skipping design causes implementation churn

[SENIOR INSIGHT] A team that jumps straight from a requirement to writing code, without a deliberate design step, is implicitly doing HLD and LLD while writing code — which sounds efficient but has a specific, real cost: a structural decision (which database to use, how two services should communicate, what the core data model looks like) discovered to be wrong after significant code has been written around it is far more expensive to change than the same decision reconsidered on a whiteboard or in a design document before any code exists. This is directly analogous to Chapter 4's point about requirements changes: the cost of a design mistake scales sharply with how much has already been built on top of the flawed assumption, which is exactly why a deliberate (even if brief, for a small project) design step pays for itself.

Matching design rigor to the project's actual stakes

[IN PRACTICE] Directly extending Chapter 3's "match process to context" theme: a small, low-risk feature might need only a brief design conversation captured in a few sentences on the ticket itself; a major new service or a change to a core, widely-depended-upon system genuinely warrants a written design document, reviewed by relevant stakeholders before implementation begins — the design review process itself is where many costly structural mistakes get caught, by people who weren't involved in the requirements/initial thinking and can bring a fresh, critical perspective (directly the same value the companion Code Reviews book's Chapter 1 identifies for code review, applied one stage earlier in the lifecycle).

## Lightweight design (appropriate for a small, well-understood feature)
Adding a "reorder" button per Chapter 4's user story. Approach: new
`POST /orders/:id/reorder` endpoint, reusing existing `CartService.addItem()`
for each line item. No new tables needed. ~1 paragraph, captured directly
in the ticket, no separate review needed beyond the eventual code review.

## Formal design document (appropriate for a major new system)
# Design: Real-Time Order Notification Service
## Problem statement
## Requirements (functional and non-functional, referencing Chapter 4)
## Proposed architecture (HLD: services involved, data flow diagram)
## Alternatives considered and rejected, with reasoning
## Detailed design (LLD: schema, API contracts, key algorithms)
## Rollout plan (referencing Chapter 9's deployment strategies)
## Open questions for reviewers

Common mistakes

1. Skipping a deliberate design step for anything beyond a genuinely trivial change, effectively doing HLD/LLD ad hoc while writing code, and discovering structural problems only after significant implementation effort is already invested.
2. Writing an exhaustively formal design document for a small, low-risk feature, wasting effort on process ceremony disproportionate to the actual stakes — matching design rigor to context (Chapter 3's theme) applies here directly.
3. Not having anyone outside the original requirements/design conversation review a major design before implementation begins, missing the fresh-perspective value a design review provides — directly analogous to code review's value, applied one stage earlier.
4. Treating a design document as a one-time artifact never revisited, rather than updating it (or explicitly noting deviations) as implementation reveals details the original design didn't anticipate — a design is a starting plan, not an immutable contract with reality.

Checklist: running an effective design phase

1. Match design rigor to the change's actual stakes — a brief note for a small feature, a formal, reviewed document for a major new system or a change to a widely-depended-upon component.
2. Explicitly separate high-level design (major components, data flow, technology choices) from low-level design (schemas, APIs, class structures), even informally, since they require different kinds of thinking and often different reviewers.
3. Get a design reviewed by someone outside the original thinking before implementation begins, for anything beyond a trivial change — this catches structural issues far more cheaply than a code review after implementation would.
4. Treat a design document as a living reference during implementation, updating it or explicitly noting deviations as reality reveals details the original design didn't anticipate.

Discussion / interview questions

1. "What's the relationship between requirements, high-level design, and low-level design in the SDLC?" Strong answer: Requirements determine what needs to be built; HLD determines the major components, their responsibilities, and how they interact; LLD determines the specific implementation details (schemas, APIs, class structures) within each component — a progression from "what" to increasingly concrete "how," each stage informing the next.

2. "Why does skipping a deliberate design phase tend to cause implementation churn?" Strong answer: Without a deliberate design step, structural decisions get made implicitly while writing code, and a decision that turns out to be wrong is discovered only after significant code has been built around it — far more expensive to fix at that point than if reconsidered on paper before implementation began.

3. "How would you decide how much design rigor a given feature or project warrants?" Strong answer: Match rigor to actual stakes — a small, well-understood, low-risk feature needs only a brief design note; a major new service or a change to a widely-depended-upon system warrants a formal, reviewed design document, since the cost of an undiscovered structural mistake is much higher there.

4. "Why is having someone outside the original design conversation review it before implementation begins valuable?" Strong answer: A fresh perspective can catch structural issues, unconsidered alternatives, or unstated assumptions that the original thinkers, close to the problem, might miss — directly the same value code review provides, applied one stage earlier in the lifecycle, where a caught issue is even cheaper to fix.

Chapter summary / cheat sheet

• Design translates "what" (requirements) into "how," at two levels: HLD (major components, data flow, technology choices) and LLD (schemas, APIs, class structures) — see the companion HLD & LLD book for full depth.
• Skipping deliberate design causes implementation churn — a structural mistake discovered after significant code exists is far more expensive to fix than one caught on paper beforehand.
• Match design rigor to actual stakes: brief notes for small features, formal reviewed documents for major systems or widely-depended-upon components.
• A design review before implementation catches structural issues cheaply, via the same fresh-perspective value code review provides — a design document should be treated as a living reference, updated as implementation reveals new details.

---