Chapter-End Drill System
Why this page matters
Reading architecture material is not enough. Each chapter should produce an artifact, a decision, or a review action. This drill system standardizes practice across the book.
Drill format
Use this structure at the end of any chapter or study session:
| Section | What to write |
|---|---|
| Scenario | realistic product/team constraint |
| Decision prompt | the architectural choice you must make |
| Expected architect answer | outcome, constraints, options, decision, tradeoffs, verification |
| Weak-answer signals | tool-first answer, missing failure modes, no owner, no production evidence |
| Artifact | ADR, matrix, map, review packet, scorecard, or diagram |
Universal drill template
## Architecture drill
### Scenario
### Decision prompt
### Expected architect-level answer
### Common weak answers
### Artifact to produce
Expected answer rubric
| Level | Signal |
|---|---|
| junior | names implementation steps without constraints |
| senior | explains a clean local solution |
| staff | names cross-team boundaries, risks, and rollout |
| architect | frames decision criteria, tradeoffs, verification, and operating model |
Drill bank by topic
| Topic | Scenario | Artifact |
|---|---|---|
| Part 0 foundation | critical route lacks owner, budgets, and failure states | readiness packet |
| decision-making | team argues about SSR vs CSR | ADR with option scoring |
| runtime | page has poor INP after hydration | runtime diagnosis note |
| rendering/data | dashboard mixes URL, server, and global state | route/data matrix |
| modularity | shared utilities folder becomes product logic | boundary ADR |
| performance | marketing route regresses after new experiment | budget and rollback plan |
| design system | teams fork Button and Dialog | component API review |
| security/privacy | third-party script needs sensitive route access | threat model and script register |
| reliability | one API outage collapses a dashboard | degradation matrix |
| GenUI | copilot wants to call a destructive tool | tool-risk policy and eval |
Common weak answers
- "Use Next.js/React Query/Tailwind" without tying the tool to constraints.
- "Add tests" without naming which failure mode the tests prove.
- "Use a global store" without state ownership rules.
- "Add caching" without freshness, invalidation, and privacy rules.
- "Monitor it" without metrics, ownership, threshold, and action.
- "Ask for approval" for AI/tool actions without server policy and audit.
Review checklist
- Does the drill force a decision rather than only recall?
- Does the expected answer name constraints, tradeoffs, and verification?
- Does the artifact prove architectural judgment?
- Are weak-answer signals concrete enough for self-review?
Exercises
- Convert three chapters you have read into the universal drill template.
- Grade one of your own answers using the expected answer rubric.
- Add one weak-answer signal to a capstone review.
Source lens
Use this drill system with Part 0, system-design interviews, capstones, rubrics, and review packets.