An engineer joins a new company. On the first day they receive a 400-page architecture document. On the second day there is an incident. On the third day they are asked whether the system should use synchronous calls or event-driven architecture for a new feature. The document is too long to reread. The post-mortem is still in progress. The decision is due by end of day.
Every engineer who has changed jobs has had this week. The question is not whether this pressure will arrive — it will. The question is whether you have a map.
The nine frameworks are that map. Not a list to memorise, but a system with internal logic. Here is how they fit together.
The Nine at a Glance
| # | Framework | What It Gives You |
|---|---|---|
| F1 | 12 Mental Models | How to see a system |
| F2 | 15 Engineering Principles | What properties a healthy system must have |
| F3 | 12 Failure Modes | What breaks, and how to name it |
| F4 | 10 Architecture Tradeoffs | The vocabulary for every design decision |
| F5 | 7 Review Questions | The checklist for evaluating any system |
| F6 | 6 System Archetypes | System type and implied failure patterns |
| F7 | 5 Architecture Diagrams | How to see and communicate a system |
| F8 | 26 Infrastructure Components | The building blocks |
| F9 | 16 Engineering Laws | Empirical and mathematical constraints |
How They Relate
The nine frameworks are not independent. They form a system with internal dependencies.
F1 (Mental Models) is the lens. Before you apply any other framework, you must see the system correctly. An engineer whose primary model is Flow notices throughput problems first. An engineer whose primary model is State notices consistency problems first. F1 ensures you are looking at the full picture before drawing conclusions.
F2 (Engineering Principles) is the guardrails. Once you see the system, the principles name the properties it must have to be healthy: observability, idempotency, fault tolerance, consistency. 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. F3 is both a naming system for post-mortems and a pre-mortem checklist for design reviews.
F4 (Architecture Tradeoffs) is the decision vocabulary. Every architectural decision trades one property for another. Consistency vs Availability. Latency vs Throughput. Coupling vs Cohesion. A decision described without naming its tradeoff is incomplete. F4 is the ten primary dials and the language to discuss them precisely.
F5 (Review Questions) is the process. Seven questions, applied in dependency order, cover every major failure surface of a system. F5 does not tell you what the answers are — it tells you which questions to ask before a decision is made.
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 and which tradeoffs will dominate.
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 the right one is the fastest way to communicate a concern in a design review or post-mortem.
F8 (Infrastructure Components) is the vocabulary. Twenty-six components — load balancers, caches, message queues, databases — are the building blocks. 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. Moore's Law, Conway's Law, Hyrum's Law, CAP — these are constraints on the design space, not guidelines. You cannot engineer around them. You can only design with them in mind.
The Dependency Chain
The frameworks have a natural reading order for decision-making:
Identify archetype (F6)
→ Apply mental models to see the system (F1)
→ Check principles — what properties must it have? (F2)
→ Run review questions — what is the failure surface? (F5)
→ Name the tradeoffs — what are you choosing? (F4)
→ Pre-mortem — which failure modes are you creating? (F3)
→ Draw the diagrams — communicate what you found (F7)
→ Name the components — build vocabulary (F8)
→ Check the laws — what constrains your choices? (F9)
This is not the only order. In a post-mortem you start at F3 — name the failure mode first. In a system design interview you start at F6 — classify the archetype. When you join a new codebase you start at F7 — draw the five diagrams from what you can read; gaps in the diagrams are gaps in your understanding.
Entering from a Problem
You are in an incident. Start at F3: which failure mode is this? Name it. Then use F7 to draw the failure path (not the happy path). Then ask: which F5 review question would have caught this before production?
You are in a design review. Start at F6: what archetype is this? That tells you which F4 tradeoffs will dominate. Run F5. Then use F3 as a pre-mortem: for each component, what is the failure mode if it is unavailable?
You are new to a system. Start at F7: draw the five diagrams from whatever documentation exists. Gaps in the diagrams are gaps in the design. Then classify using F6. Then run F5 to find the failure surfaces.
The frameworks are not useful as a list. They are useful as a map — one you enter from wherever the problem is and navigate toward clarity. The map is the same every time. The entry point changes.