All playbooks
Playbook · Design and build · 9 steps
Reviewing a solution design
Spend review time where the irreversible risks live.
“The first principle is that you must not fool yourself—and you are the easiest person to fool.”
- 1C4 Model (Zoom Levels for Audiences)Is there a context diagram everyone in the review agrees on before diving into detail?Draw architecture as a few maps at different zoom levels — context, containers, components, code — and show each audience the level it needs.Open
- 2Everything Is a Trade-offCan the author name what each option gives up?There are no best practices, only trade-offs in context. If you can't name the downside, you don't understand the choice.Open
- 3Coupling and CohesionDo the boundaries follow what changes together?Keep things that change together close together, and things that change independently apart.Open
- 4Fallacies of Distributed ComputingWhat happens when each remote call fails or slows down?The network is not reliable, latency is not zero, and bandwidth is not infinite. Design as if you know it.Open
- 5Blast RadiusWhat is the worst thing a single fault can take down, and is that a deliberate choice?Limit how much can break when any one thing fails.Open
- 6Hyrum's LawWhich behaviour of the new interfaces will consumers start relying on?With enough users, every observable behaviour of your API will be depended on by somebody.Open
- 7Fitness FunctionsWhich of the qualities we care about can be checked automatically from now on?Protect the qualities that matter with automated checks, so the architecture can change safely.Open
- 8Second-Order ThinkingWhat will this design make easy — and therefore likely — next year?Ask “and then what?” The consequences of consequences are where architectures succeed or fail.Open
- 9Bikeshedding (Law of Triviality)Are we spending our time on the decisions that matter most?Groups spend disproportionate time on trivial issues because everyone feels qualified to discuss them.Open