We have it backwards. Most engineers start with AI, describing problems and refining solutions without understanding why systems work or fail. The correct approach reverses this: develop thinking frameworks first, then use AI to evaluate generated solutions.
AI operates in the space of possibility. It generates options. It does not select under constraints, reason about second-order effects, or own consequences. That part stays human.
1. Mental models — how to interpret a system in the first place
Systems combine twelve recurring patterns: transformation, search, optimisation, flow, state, networks, feedback, concurrency, redundancy, layered abstraction, indirection, and tradeoffs. Recognizing patterns reveals behavior under stress — a load balancer is a hashing function applied to distribution; a circuit breaker combines feedback loops with state machines.
2. Engineering principles — what good systems are built from
Fifteen properties characterize well-designed systems: abstraction, modularity, composability, separation of concerns, idempotency, reproducibility, immutability, locality, fault tolerance, observability, consistency, security boundaries, fail fast, least privilege, and measure and adapt. Missing principles create predictable failures: absent idempotency causes duplicate retries; missing observability hides failures; lacking locality compounds latency across services.
3. Failure modes — not whether it will fail, but how
Twelve failure patterns occur in distributed systems:
- Single point of failure
- Cascading failures
- Unbounded resource consumption
- Data consistency failure
- Latency amplification
- Hotspotting
- Thundering herd
- Schema and contract violation
- Silent data corruption
- Security breach
- Observability blindness
- Split-brain
4. Architecture tradeoffs — every decision is an optimisation under constraints
Core tradeoffs include: consistency vs availability, latency vs throughput, simplicity vs flexibility, precomputation vs on-demand computation, centralisation vs distribution, generality vs specialisation, automation vs control, coupling vs cohesion, correctness vs performance, and synchronous vs asynchronous. Naming these choices enables conscious decisions rather than accidental ones.
5. Architecture review questions — how to expose what a design is hiding
Seven questions surface hidden assumptions:
- What breaks at ten times current load?
- What happens when each component fails?
- Where is state stored, and can it replicate?
- What are latency bottlenecks in the request path?
- Can schemas, message formats, and API contracts change without rewrites?
- What are security boundaries and excessive access permissions?
- Can you observe the system through metrics, logs, and traces?
The most commonly skipped question is the last one. It is also the one that makes every other failure mode worse.
6. System archetypes — most systems are not new
Six recurring categories exist:
- Search and discovery
- Social and communication
- Marketplace and transaction
- Media delivery
- Data intelligence
- Platform and API
YouTube combines media delivery, search, and social. Uber merges marketplace with data intelligence. Identifying archetypes reveals likely tradeoffs, required infrastructure, and battle-tested patterns.
7. Architecture diagrams — if you cannot draw it, you do not understand it
Five diagram types provide complete system pictures:
- Request flow diagrams
- Data storage diagrams
- Event-driven diagrams
- Data pipeline diagrams
- Distributed coordination diagrams
Most system designs are drawn with only the first. The failure mode is usually hiding in one of the other four.
8. Infrastructure components — abstractions must stay grounded
Twenty-six standard components comprise production systems: DNS, CDN, load balancer, API gateway, web servers, application services, service discovery, task queues, message queues, stream processors, cache layer, primary database, read replicas, distributed storage, search index, vector database, analytics warehouse, time-series database, batch processing engine, scheduler, monitoring, logging, distributed tracing, authentication service, authorisation system, and configuration/feature flag service.
9. Engineering laws — constraints that cannot be negotiated away
Mathematical constraints:
- Amdahl's Law: parallelism speedup is bounded by sequential fractions
- CAP theorem: distributed systems cannot guarantee consistency, availability, and partition tolerance simultaneously
- Little's Law: average queue length equals arrival rate times average system time
Human behavior patterns:
- Conway's Law: systems mirror team communication structures
- Goodhart's Law: metrics become ineffective when targeted
- Hofstadter's Law: tasks exceed estimates despite accounting for delays
Why this matters now
In a world where AI can generate a solution to almost any well-specified problem, the bottleneck has shifted. The bottleneck is now the quality of the question and the quality of the evaluation.
These frameworks enable productive AI collaboration rather than generating plausible but fragile systems. AI should rely on us being ready. These nine frameworks are what ready looks like.