An engineer joins a new company. On the first day, someone hands them a 400-page architecture document. On the second day, an incident happens. On the third day, they are asked whether the system should use synchronous calls or an event-driven approach for a new feature. The architecture document is too long to reread. The incident 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 the pressure will come — it will. The question is whether you have a map that lets you navigate fast.
The nine frameworks are that map. This chapter shows how they fit together — not as a list, but as a system.
The twelve threads in the previous chapter are the vertical spine, running through every layer of the stack. The nine frameworks are the horizontal instruments — the lenses you apply at any layer to analyse what you are looking at, make decisions, and communicate those decisions clearly.
| # | Framework | What It Gives You |
|---|---|---|
| F1 | 12 Mental Models | How to see a system |
| F2 | 15 Engineering Principles | How to build a system that will not break you |
| F3 | 12 Failure Modes | What breaks, and how |
| F4 | 10 Architecture Tradeoffs | The vocabulary for every design decision |
| F5 | 7 Architecture 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 | The empirical and mathematical constraints |
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.
The frameworks have a natural reading order for decision-making:
This is not the only order. In a post-mortem you start at F3. In a job interview you start at F6. In a system design session you start at F5. The chain shows dependencies, not sequence.
The map is most useful when you enter it from a real problem, not from the beginning.
You are in an incident. Something is broken. Start at F3: which failure mode is this? Name it. Then use F7 to draw the failure path (not the happy path). Then use F5 to ask: which review question would have caught this before production?
You are in a design review. Something is being proposed. Start at F6: what archetype is this? That tells you which tradeoffs from F4 will dominate. Then run F5. Then use F3 as a pre-mortem: for each component, what is the failure mode if it is unavailable or returns incorrect data?
You are new to a system. You have a codebase, some documentation, and many questions. Start at F7: draw the five diagrams from what you can read. Gaps in the diagrams are gaps in your understanding. Then classify using F6. Then run F5 to find the failure surfaces.
You are in a career question. Should you take this technical direction? Apply F4: what tradeoffs does this choice make? Apply F9: which laws constrain what you can achieve? Apply F2: what principles does this decision preserve or violate?
The diagram that follows — the one-page map of all nine frameworks — is the signature artefact of this book and the series. It shows:
Print it. Put it somewhere you see it. The value of the map is not reading it — it is having it so close to hand that you stop needing to consult it.