Core Concepts Overview
Use core concepts as tools for explaining a workload, not as vocabulary to recite.
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 shapeWorked 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
| If the problem is… | Revisit | Probe |
|---|---|---|
| Request path or latency | Networking Essentials | Where is time spent? |
| Contract ambiguity | API Design | What does retry mean? |
| Ownership or query shape | Data Modeling + Indexing | Which key and access pattern? |
| Freshness or uneven growth | Caching + sharding | What is authoritative and where is skew? |
| Partition behavior | CAP + estimation | What fails and at what scale? |
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.
Show answer and explanation
Answer: Choose a measured bottleneck and connect it to a specific mechanism. For example, a hot key may need partitioned aggregation, while slow selective lookup may need an index. State the invariant and failure path; topic names alone do not justify the design.