Google’s Capacity Planning treats back-of-envelope estimation as a discipline, not an approximation. Their Site Reliability Engineering book documents the estimation process used before any major feature launch.
Amazon’s Six-Pager requires written characterisation of scale requirements before any system is designed. The document includes estimated load, growth projections, and failure scenarios — all non-functional requirements made explicit.
Stripe’s RFC Process requires that any system design document state the read and write QPS, storage requirements, and latency targets as the first section. Architecture decisions are not evaluated without those numbers.
Twitter’s Capacity Model (documented in their engineering blog) showed that the fan-out problem — a celebrity post triggering millions of feed updates — was invisible in back-of-envelope estimates that used average follower counts. The p99.9 case, not the average, drove the architecture.
Concept: Requirements to Architecture Translation
Thread: T12 (Tradeoffs) ← Ch 1 (Design Process) → Ch 3 (Distributed KV Store)
Core Idea: Product requirements must be translated into quantified engineering constraints — QPS, storage, bandwidth, consistency level — before any architecture decision can be evaluated. Numbers eliminate whole classes of solutions.
Tradeoff: AT1 — Consistency vs Availability: the highest-leverage decision, made once the consistency requirement is quantified from product requirements.
Failure Mode: FM4 — Data Consistency Failure: choosing eventual consistency without specifying the acceptable staleness window leads to anomalies users observe directly.
Signal: When a product requirement lacks explicit scale or consistency targets and an architecture decision must be made.
Maps to: Reference Book, Framework 6 (System Archetypes)