Chapter 3: HLD Deliverables: Architecture, Components, Technology Choices, Data Flow

Why this matters

An HLD document is only useful if it actually contains the specific deliverables that let reviewers evaluate it and implementers build from it — a vague architecture narrative with no concrete diagram or component responsibility breakdown fails at both jobs simultaneously. This chapter covers the four deliverables every solid HLD document should contain.

Deliverable 1: an architecture diagram

[BEGINNER] The single most important HLD artifact — a diagram showing the major components and how they connect, precise enough that someone could redraw it from a verbal description alone (this book's own diagramming convention throughout). Directly building on the companion System Design book's Chapter 2 building blocks:

+----------+     +----------------+     +------------------+
|  Client  |---->| API Gateway    |---->| Booking Service   |
+----------+     +----------------+     +------------------+
                         |                        |
                         |                        v
                         |               +------------------+
                         |               | Booking Database  |
                         |               +------------------+
                         v
                +------------------+
                | Notification     |
                | Service          |
                +------------------+

Deliverable 2: component responsibility descriptions

[SENIOR INSIGHT] A diagram alone shows what connects to what, but not why each component exists or what it's specifically responsible for — this is exactly the OOP book's Chapter 9 Single Responsibility Principle, applied at the architecture-diagram scale: each box in the diagram should have a one-or-two-sentence statement of its responsibility, and if you can't write that sentence cleanly (it requires "and," joining unrelated concerns), that's a signal the component boundary itself may be drawn incorrectly, directly the companion System Design book's Chapter 11 service-boundary guidance.

## Component responsibilities
- **API Gateway**: authenticates requests, routes to the appropriate
  internal service, applies rate limiting (companion System Design
  book, Chapters 9 and 17).
- **Booking Service**: owns the booking lifecycle (create, confirm,
  cancel) and enforces booking-specific business rules.
- **Notification Service**: sends confirmation/reminder messages via
  email/SMS, decoupled from the booking flow via an async event
  (companion System Design book, Chapter 8).

Deliverable 3: technology choices, with reasoning

[BEGINNER] Every major technology choice (which database, which message queue, which communication protocol between services) should be stated explicitly along with the reasoning — directly feeding into Chapter 6's ADR discipline. A reviewer evaluating an HLD needs to understand why PostgreSQL was chosen over MongoDB for this specific system, not just that it was chosen, to meaningfully evaluate whether the choice is sound.

Deliverable 4: data flow through the system

[IN PRACTICE] Beyond the static architecture diagram, a data flow description traces what happens, step by step, for the system's most important operations — this is often best expressed as a simple numbered sequence overlaid on the architecture diagram, or as a dedicated sequence diagram (Chapter 4 covers sequence diagrams at the LLD level in more mechanical detail; a lighter-weight version belongs in the HLD to establish the overall flow before LLD gets into per-component specifics):

Data flow: "Create a booking"
1. Client sends a create-booking request to the API Gateway.
2. API Gateway authenticates and routes to the Booking Service.
3. Booking Service validates availability against the Booking Database.
4. Booking Service writes the new booking record.
5. Booking Service publishes a "booking.created" event.
6. Notification Service (subscribed to this event) sends a confirmation
   message, asynchronously, AFTER the client has already received a
   response in step 4 -- the notification is NOT on the synchronous
   critical path (companion System Design book, Chapter 8).

Capacity estimates belong in the HLD, not just implied

[SENIOR INSIGHT] Directly the companion System Design book's Chapter 4 back-of-envelope estimation, made an explicit, written HLD deliverable rather than an implicit, unstated assumption: stating "this system is designed for ~5,000 requests/second peak and ~500GB of data growth per year" in the HLD document itself gives every subsequent LLD decision (should this component be sharded? does this need a cache?) a concrete, shared reference point, rather than each component's LLD author guessing at or re-deriving the system's actual scale independently.

Common mistakes

1. Producing an architecture diagram with no accompanying component responsibility descriptions, leaving reviewers to guess why each component exists or what specifically it should and shouldn't do.
2. Choosing technologies without documenting the reasoning, making the HLD much harder to evaluate meaningfully (a reviewer can only rubber-stamp a choice they can't actually assess) and much harder to revisit correctly later (Chapter 6's ADR discipline exists specifically to prevent this).
3. Describing only the static architecture without tracing data flow for the system's key operations, missing a common source of design flaws (a step that turns out to need to be synchronous when it was assumed asynchronous, or vice versa) that only becomes visible when tracing an actual operation through the diagram.
4. Leaving capacity estimates implicit or undocumented, forcing every subsequent LLD decision to guess at or re-derive the system's actual intended scale independently, risking inconsistent assumptions across different components' LLD work.

Checklist: producing a complete HLD

1. Include an architecture diagram precise enough to redraw from a verbal description alone.
2. Write a one-or-two-sentence responsibility statement for every component — if it needs "and" to join unrelated concerns, reconsider the boundary.
3. Document every major technology choice's reasoning explicitly, not just the choice itself.
4. Trace data flow for the system's most important operations, distinguishing synchronous critical-path steps from asynchronous, off-path ones.
5. State capacity estimates explicitly in the HLD document, giving every subsequent LLD decision a concrete, shared reference point.

Discussion / interview questions

1. "What are the key deliverables of a complete HLD document?" Strong answer: An architecture diagram, component responsibility descriptions, documented technology choices with reasoning, data flow tracing for key operations, and explicit capacity estimates — a document missing any of these is harder for reviewers to evaluate and harder for LLD authors to build from correctly.

2. "Why should each component in an HLD diagram have an explicit, statable responsibility?" Strong answer: This is Single Responsibility Principle applied at the architecture scale — if a component's responsibility can't be stated cleanly in one sentence without "and," that's a signal the component boundary may be drawn incorrectly, joining concerns that should probably be separated.

3. "Why is documenting the reasoning behind a technology choice as important as documenting the choice itself?" Strong answer: A reviewer can only meaningfully evaluate a choice they understand the reasoning for — an undocumented choice can only be rubber-stamped, not genuinely assessed, and it's much harder to correctly revisit later without the original reasoning preserved (directly feeding Chapter 6's ADR discipline).

4. "Why should capacity estimates be stated explicitly in the HLD rather than left implicit?" Strong answer: Explicit estimates give every subsequent LLD decision (sharding, caching, indexing) a concrete, shared reference point; leaving them implicit risks each component's LLD author guessing independently, potentially with inconsistent assumptions about the system's actual intended scale.

Chapter summary / cheat sheet

• Four essential HLD deliverables: architecture diagram, component responsibility descriptions, technology choices with documented reasoning, and data flow tracing for key operations.
• Component responsibilities should be statable in one clean sentence — needing "and" signals a possibly-misdrawn boundary (Single Responsibility, applied architecturally).
• Technology choice reasoning should be documented, not just the choice — this enables genuine review and correct future revisiting (Chapter 6).
• Capacity estimates belong explicitly in the HLD document, giving every subsequent LLD decision a shared, concrete reference point.

---