Chapter 2: Core Building Blocks and Vocabulary

Why this matters

System design conversations move fast, and they rely on a shared vocabulary of building blocks that every participant is expected to recognize instantly — clients, load balancers, caches, CDNs, queues, databases, services. This chapter is a fast, precise survey of each, deliberately brief on mechanics already covered in depth in this book series' companion volumes, and focused instead on each block's role in a larger system.

The building blocks, and where each one's deep mechanics live

[BEGINNER]

• Client — whatever originates a request: a browser, a mobile app, another service. In system design diagrams, the client is usually drawn as the starting point of every request flow.
• Load balancer — distributes incoming requests across multiple backend servers, enabling horizontal scaling and fault tolerance (full mechanics: companion Networking book, Chapter 8).
• Cache — stores frequently-accessed data in fast-access storage to avoid repeatedly recomputing or re-fetching it from a slower source (full mechanics: this book's Chapter 5, and the companion Database book's Chapter 12).
• CDN (Content Delivery Network) — caches content geographically close to users, reducing physics-bound latency for static or slowly-changing content (full mechanics: companion Networking book, Chapter 8).
• Queue / message broker — decouples producers of work from consumers, enabling asynchronous processing and absorbing load spikes (full mechanics: this book's Chapter 8, and the companion Design Patterns book's Chapter 16 on Event-Driven Architecture).
• Database — the system of record for persistent data, relational or NoSQL (full mechanics: the entire companion Database book; this book's Chapter 7 covers the systems-level selection/scaling view specifically).
• Service — a distinct, independently-deployable unit of business logic, communicating with other services typically over a network (full mechanics: this book's Chapter 11 on microservices vs. monoliths).

Assembling the blocks into a request flow

[IN PRACTICE] A typical request through a reasonably-scaled web system touches several of these blocks in sequence — being able to draw and narrate this flow fluently is a foundational system design skill in its own right, since nearly every specific design question is really a variation on "where in this flow does the interesting complexity live":

Client
  |
  v
CDN (serves static assets directly; forwards dynamic requests onward)
  |
  v
Load Balancer (distributes across many backend server instances)
  |
  v
Service (application/business logic) ----> Cache (checked first for hot data)
  |                                              |
  v                                              v
Database (source of truth)  <----(cache miss falls through to here)
  |
  v
[Response travels back up the same path to the client]

(Separately, off the main synchronous request path:)
Service ----> Queue ----> Background Worker (async processing: sending
                                              an email, generating a
                                              report, etc. -- decoupled
                                              from the request/response
                                              cycle entirely)

Why vocabulary precision matters beyond just sounding informed

[SENIOR INSIGHT] Precise vocabulary isn't pedantry — it's what lets a design conversation move quickly without constant re-explanation, and it's what lets you draw on this entire book series' deeper material by reference rather than re-deriving it from scratch in every conversation. Saying "we'd put a cache here" versus "we'd put a write-through cache with a 5-minute TTL here, invalidated explicitly on write" (Chapter 5's specific vocabulary) conveys a materially different, more complete design in the same number of words — precision is a form of compression that lets a design conversation cover much more ground in a fixed amount of time.

Common mistakes

1. Using "cache," "queue," or "database" as if each were one undifferentiated thing, without the more precise vocabulary (write-through vs. cache-aside, message queue vs. pub/sub, relational vs. document) that actually communicates a specific design decision.
2. Not being able to draw and narrate a basic request flow fluently, which is often the very first thing a system design conversation (interview or otherwise) needs to establish before any interesting complexity can even be discussed.
3. Conflating synchronous request-path components with asynchronous, off-path components (a queue-driven background worker) as if they were interchangeable — they serve fundamentally different purposes (immediate response vs. decoupled, delayed processing).
4. Re-deriving deep component mechanics from scratch in every system design conversation, rather than referencing established, precise vocabulary (from this book series' companion volumes) and spending the actual conversation time on the trade-off reasoning that's unique to the system at hand.

Checklist: using system design vocabulary effectively

1. Use precise, specific terminology for each building block (write-through cache, leader-follower replication, message queue vs. pub/sub) rather than generic, undifferentiated terms.
2. Practice drawing and narrating a basic request flow fluently, distinguishing the synchronous request path from asynchronous, off-path processing.
3. Reference deeper component mechanics rather than re-deriving them — this book series' companion volumes (Database, Networking, Design Patterns) hold that depth; a system design conversation should build on it, not repeat it.
4. Match vocabulary precision to the actual design decision being communicated — precise terms should convey a specific, meaningful choice, not just demonstrate familiarity with jargon.

Discussion / interview questions

1. "Draw and narrate the basic flow of a request through a typical, reasonably-scaled web system." Strong answer: Client → CDN (static assets) → load balancer → service (checking a cache first) → database (on a cache miss) → response back up the same path, with a separate note about asynchronous work flowing through a queue to background workers off the main request path.

2. "Why does precise vocabulary (e.g., 'write-through cache' vs. just 'cache') matter in a system design discussion?" Strong answer: Precise vocabulary compresses a complete, specific design decision into a few words, letting a conversation move faster and cover more ground without needing constant re-explanation — imprecise terms leave a design decision ambiguous or fully unstated.

3. "What's the difference between a system's synchronous request path and its asynchronous processing path?" Strong answer: The synchronous path handles a client's request and must respond within the request's lifetime (client → load balancer → service → database/cache → response); the asynchronous path (service → queue → background worker) handles work that can be decoupled from the immediate response, processed after the client has already received their reply.

4. "Why might a system design conversation reference the companion Database or Networking material rather than re-explaining those mechanics from scratch?" Strong answer: System design's actual value is in trade-off reasoning at the integration level — re-deriving deep component mechanics (how B-tree indexes work, how TCP handshakes function) from scratch wastes conversation time that should go toward the trade-offs unique to the specific system being designed.

Chapter summary / cheat sheet

• Core building blocks: client, load balancer, cache, CDN, queue/message broker, database, service — each with deep mechanics covered in this book series' companion volumes, referenced here rather than re-derived.
• A typical request flow: client → CDN → load balancer → service (cache-first) → database, with asynchronous work flowing separately through a queue to background workers.
• Precise vocabulary (write-through cache, leader-follower replication) compresses a complete design decision into few words — this is a genuine efficiency tool for design conversations, not pedantry.
• Fluency in drawing and narrating a basic request flow is a foundational skill nearly every system design conversation builds on.

---