The goal isn't to memorize a diagram. Start with explicit constraints, build a workable version, then change a condition and see where the design breaks.
These are original teaching exercises, not company interview questions or production configurations.
Choose an exercise
| Exercise | Main skill | Easy mistake |
|---|---|---|
| Recommendation feed | Retrieval, ranking, freshness, and fallbacks | Ranking cannot recover an item retrieval missed |
| Knowledge-base answers with citations | Indexing, retrieval, permissions, and evidence | Seeing a document doesn't make an answer supported |
| Editable long-term memory | Writes, conflicts, retrieval, and deletion | Superseded information can still be retrieved |
How to practice
Spend five minutes writing goals, non-goals, and constraints. Draw the data flow and give each arrow an input and output. Then challenge the design with a timeout, stale information, a distribution shift, or a revoked permission.
More components don't necessarily mean a better design. Removing one while preserving the important properties often shows deeper understanding.
Design exercises versus implementation studies
Both belong in Engineering practice. Design exercises start from requirements and let you state assumptions and compare alternatives. Implementation studies start from existing code: what does it actually do, and what remains unknown? Original teaching projects are labeled separately; a design we propose is not evidence of a company's production architecture.
The system-design reading guide keeps the resource list. Return to Foundations for the concepts, or to Interview preparation for questions, ML coding, and algorithms.