The nine frameworks are not independent. They form a system with internal logic.
F1 (Mental Models) is the lens. Before you can apply any other framework, you must see the system correctly. Mental models determine what you notice and what you miss. An engineer whose primary mental model is Flow will notice throughput problems first. An engineer whose primary model is State will notice consistency problems first. The twelve mental models ensure you are looking at the full picture.
F2 (Engineering Principles) is the guardrails. Once you see the system, the principles tell you what properties it must have to be healthy. Observability, idempotency, fault tolerance, consistency — these are not design aspirations. They are engineering requirements. Every principle in F2 is a property whose absence creates a failure mode in F3.
F3 (Failure Modes) is what goes wrong. Every system will eventually exhibit one or more of the twelve failure modes. SPOF, cascading failures, data consistency failures, silent data corruption — these are the failure taxonomy. When something breaks, you name it from F3. When designing, you use F3 as a pre-mortem checklist.
F4 (Architecture Tradeoffs) is the decision vocabulary. Every architectural decision trades one property for another. Consistency vs Availability. Latency vs Throughput. Coupling vs Cohesion. F4 gives you the ten primary dials and the language to talk about them precisely. A decision described without naming its tradeoff is incomplete.
F5 (Review Questions) is the process. Seven questions, applied in dependency order, cover every major failure surface of a system. They are the checklist for an architecture review or a system design interview. F5 tells you not what the answers are but what questions to ask.
F6 (System Archetypes) is the context. Systems fall into recognisable categories: Search & Discovery, Social & Communication, Marketplace & Transaction, Media Delivery, Data Intelligence, Platform & API. Identifying the archetype tells you which failure modes are most likely, which tradeoffs are most important, and which infrastructure components will dominate. It is the shortest path to useful context on an unfamiliar system.
F7 (Architecture Diagrams) is the communication. Five diagram types — Request Flow, Data Storage, Event-Driven, Data Pipeline, Distributed Coordination — each reveal a different structural property of the system. Drawing all five on a new system is the fastest way to understand it. Drawing the right one is the fastest way to communicate a concern.
F8 (Infrastructure Components) is the vocabulary. Twenty-six components — load balancers, caches, message queues, databases, and so on — are the building blocks that infrastructure patterns use. Fluency in F8 means you can name what each component does, what it guarantees, and what breaks if it is absent.
F9 (Engineering Laws) is the empirical grounding. The laws describe how systems and organisations actually behave — Moore’s Law on compute costs, Conway’s Law on organisations and architecture, Hyrum’s Law on API backwards compatibility, CAP on distributed consistency. They are constraints on the design space. You cannot engineer around them; you can only design with them in mind.