A connected reference for systems design
When code is cheap, systems design matters more.
AI writes the code now. The lasting work is judgment: where to draw boundaries, which tradeoffs to accept, what to constrain. Systems Playbook is a connected atlas of 181 durable ideas, distilled from 19 classic books, built to think with.
- Ideas
- 181
- Mental models
- 14
- Sources
- 19
Where to start
Open a shelf
Jump straight into a layer of the graph, or run a filtered search across everything.
Filter by type, category, or source, then inspect first-degree relationships.
Reading paths 7 curated routesFollow lightweight sequences through the graph for common reader goals.
Concepts 137 entriesCore ideas, principles, biases, and system properties extracted from the playbook.
Patterns 4 entriesPromoted repeatable practices that connect ideas to concrete engineering moves.
Mental Models 14 entriesReusable lenses for reasoning about systems, organizations, products, and decisions.
Categories 7 entriesTop-level library shelves that organize the knowledge graph by domain.
References 19 entriesSource summaries that provide durable provenance for the graph.
Curated paths
Guided ways into the graph
Use these optional paths for a first pass through practical themes, then branch into related entities.
- Architecture Decision-Making
Use tradeoff thinking, quality attributes, decision records, timing, reversibility, and boundaries to structure design reviews.
- Everything Is a Tradeoff
- Architecture Characteristics
- Fitness Functions
- Decision-Making Under Uncertainty
See how human judgment is systematically bounded, then walk the specific biases that distort estimates and choices so they can be recognized in the moment.
- Judgment Is Bounded
- System 1 and System 2
- Anchoring
- Designing for Failure
Treat failure as the normal condition of a complex system and build the reasoning that follows: partial failure, latent flaws, tolerance, graceful degradation, and resilience.
- Failure Is Normal
- Partial Failure
- Latent Failures
- Judgment in the AI Era
The capstone path. When code is cheap to produce, value moves to deciding what is correct and proving it: specify intent, draw the boundaries, then verify, operate, and learn.
- Verification Over Authorship
- Ubiquitous Language
- Bounded Context
- Product and Organization Systems
Connect product direction, metrics, choice environments, Conway effects, and team interfaces as one socio-technical system.
- Start From the User
- Working Backwards
- Input vs Output Metrics
- Software Design Foundations
Work from the diagnosis that complexity is the core problem down to the concrete techniques that keep code understandable: hiding decisions, deep modules, precise names, and obvious code.
- Complexity Is the Root Cause
- Complexity
- Essential vs Accidental Complexity
- Systems Thinking Foundations
Build a first path through system structure, feedback, delays, leverage, traps, and complexity before branching into the wider graph.
- Structure Drives Behavior
- Stocks and Flows
- Feedback Loops
Starting points
Useful shelves to open first
Begin with a mental model, a promoted pattern, or a category, then follow relationship links across the graph.
- Mental ModelComplexity Is the Root Causecomplexity
Complexity, especially the accidental complexity we introduce ourselves, is the dominant source of difficulty in software, so the highest leverage work is relentlessly reducing it. The enemy is not lines of code or scale but the loss of understandability as a system grows. Com...
- Mental ModelComplexity Should Be Hiddencomplexity
Complexity is inevitable, but it should be concealed behind simple interfaces and pushed down and inward, so that most people most of the time never have to confront it. The quality of a design is measured by how little complexity it exposes, not by how clever its internals ar...
- Mental ModelConstraints Govern the Systemsystems
Every system's output is limited by a small number of constraints. Performance is set by them, so improvement comes from finding and strengthening the binding constraint, while effort spent anywhere else produces little or no gain. Bottlenecks — the constraint that caps the th...
- PatternContext Mappingarchitecture
Making the relationships between bounded contexts, and the teams that own them, explicit, so that integration between separate models is a deliberate design choice rather than an accident. Domain Driven Design names the relationship types (shared kernel, customer/supplier, con...
- PatternContinuous Deliverysystems
Keeping software in a continuously releasable state, so that shipping to users is a routine, low risk, on demand event rather than a painful, infrequent project. It is assembled from working in small batches, automating the build test deploy path so quality is built in rather...
- CategoryArchitecture
The structure of software systems: boundaries, components, and the tradeoffs between competing options. Architecture characteristics and the reasoning behind structural decisions.
- CategoryComplexity
Managing, reducing, and hiding complexity in software and systems. The distinction between essential and accidental complexity, and the techniques that keep systems understandable as they grow.
- CategoryDecision Making
How people actually judge and choose under uncertainty. Heuristics, cognitive biases, the two modes of thinking, and the bounded, predictable ways judgment departs from rationality.