Google System Design Interviews canonised the five-phase approach. Their public engineering blog documents the tradeoffs behind Bigtable, Spanner, and Chubby — each a worked example of this process.
Amazon’s Working Backwards starts from the press release (requirements) before any technical design. This is Phase 1 extended into product thinking.
Stripe’s Architecture Reviews require explicit documentation of the tradeoff space before any major technical decision. The output is an RFC (Request for Comments) that names the alternatives considered and why each was rejected — structured tradeoff documentation.
Netflix’s Chaos Engineering extends Phase 5 (evolution) into production: if you cannot reason about failure modes in advance, inject failures until you understand the system’s actual behaviour.
Concept: System Design Process
Thread: T12 (Tradeoffs) ← Book 3, Ch 1 → Ch 2 (Requirements to Architecture)
Core Idea: System design is a five-phase reasoning process — clarify, estimate, design, evaluate tradeoffs, plan evolution — not a pattern-matching exercise. Each phase produces explicit, documentable outputs.
Tradeoff: AT3 — Simplicity vs Flexibility: start with the simplest architecture that satisfies current requirements; add flexibility only at the boundaries most likely to change.
Failure Mode: FM11 — Observability Blindness: systems designed without observability cannot be debugged in production.
Signal: When you are asked to design any system from scratch and must produce a defensible architecture under time pressure.
Maps to: Reference Book, Framework 6 (System Archetypes)