The full picture
- Worked pattern 1 — 'read-heavy API, 100k RPS, p99 < 50ms': each request = 1 Redis hit (~500µs RTT) + occasionally DB (~5ms) → the network hop count is the latency budget: 50ms cross-region trip blows it alone → conclusion: regional replicas + cache-aside; the numbers made the architecture decision, not taste.
- Worked pattern 2 — 'scan or index?': 100M rows × 100B = 10GB; sequential scan at 2GB/s ≈ 5s — fine nightly, absurd per-request → index (µs) or precompute. The 100,000× gap between scan and point-lookup is the whole answer; saying '5 seconds' beats saying 'slow'.
- Worked pattern 3 — capacity: 1B events/day = ~12k/s average, ~35k/s peak (rule: peak ≈ 3× mean); at 1KB each that's 35MB/s — one Kafka broker's laugh, three for redundancy → 'the cluster is sized by durability policy, not throughput' is an architect-grade conclusion produced by division.
- Estimation hygiene: round to powers of 10, compute one dominant term (ignore the 2%), bracket ('between 1 and 10 seconds'), and always land on the design consequence — an estimate without a decision attached is trivia.