Core Concepts Overview

Use core concepts as tools for explaining a workload, not as vocabulary to recite. A design should connect the user action to a contract, state owner, data path, and failure response. This overview links the foundations chapters and gives a sequence for choosing which one to revisit.

The mechanism at a glance

Figure — User action → Request path (contract); Request path → Data model (read/write access); Data model → Scale mechanism (measured bottleneck); Scale mechanism → Failure test (stress assumption); Failure test → Design decision (revise smallest boundary)

The numbered components identify responsibilities. Follow the labeled arrows rather than treating the numbers as a global execution order. The scenario later in this lesson shows one concrete sequence.

Step-by-step reasoning

1. 1 · Frame

Start with Networking Essentials to trace a request and its latency budget, then API Design to make the client contract explicit. Use Data Modeling to identify entities and ownership. Use Database Indexing to match queries to stored state. These chapters establish the vocabulary before distributed trade-offs.

2. 2 · Model

Caching is a derived copy with a freshness contract. Sharding partitions ownership and creates skew/rebalancing questions. Consistent Hashing is a placement mechanism, not a guarantee of balanced load. CAP Theorem frames behavior during a partition; Numbers to Know uses rough arithmetic to find likely bottlenecks.

3. 3 · Scale

For each concept, ask: which request uses it, what state does it own, what invariant depends on it, and what failure makes its trade-off visible? Follow a link from the foundations section, then apply the same mechanism to a case such as Bitly, News Aggregator, or Ticketmaster.

4. 4 · Recover

Revisit a concept when a concrete design exposes a gap. A slow read may call for an index or cache; a skewed partition may need repartitioning; a concurrent update may need a conditional write. Avoid adding a technology until the contract and bottleneck justify it.

Contracts and state

The following sketch makes the decision boundary concrete. Field names and capacity assumptions are illustrative; adapt them to the stated product contract.

Concept -> relevant workload -> decision -> invariant -> failure probe
Networking Essentials -> API Design -> Data Modeling -> Indexing
Caching / Sharding / Consistent Hashing / CAP -> scale trade-offs
Numbers to Know -> estimates that test the proposed shape

Worked example

A feed needs fast reads. Estimate read volume, identify the authoritative post and follow state, then choose indexing, caching, and possibly sharding. State freshness and privacy requirements before materializing the feed. A cache is a response-time choice; it is not the place to decide whether a post is visible.

Failure walkthrough

A learner proposes sharding to fix a slow query, but the query lacks an index and reads far more rows than necessary. The overview sequence asks them to trace request/query shape first, then estimate data and traffic before changing ownership boundaries.

Figure — Prompt reveals user action → Contract and ownership are stated → Scale estimate suggests bottleneck → Relevant concept is applied → Failure probe checks the trade-off

Decisions and trade-offs

Check your understanding

Pick one system-design case and map its main bottleneck to two relevant foundation lessons. Explain why each applies and what failure would make its trade-off visible.

Open a chapter

• Networking Essentials
• API Design
• Data Modeling
• Database Indexing
• Caching
• Sharding
• Consistent Hashing
• CAP Theorem
• Numbers to Know