system-and-data-design

# System and data design — will it hold, and where does the data live Two questions that are usually asked together and answered separately, badly. Capacity without storage internals gives a diagram that cannot be built; storage internals without capacity gives a database choice with no reason behind it. ## Scope guard — read first The most common failure here is answering at the wrong scale. | Situation | Honest answer | |---|---| | Internal tool, tens of users | One process, one database, no cache. Stop. | | Product with real traffic, single region | Estimate first; add a cache and a queue only where the numbers say | | Multi-region, or data outgrowing one machine | Full pass: estimation → building blocks → replication/partitioning → consistency | Adding a cache before measuring is the canonical way to convert one problem into two. ## Step 1 — requirements before architecture - **Functional**: what must it actually do? Write it as verbs, not components. - **Non-functional, with numbers**: users, requests/sec at peak, payload size, growth, read:write ratio, acceptable latency, acceptable staleness, retention. - **Constraints**: budget, team size, existing stack, compliance, where data may live. "Acceptable staleness" is the single most useful number and the one nobody asks for. It decides caching, replication and consistency all at once. ## Step 2 — back-of-the-envelope, before any diagram Estimate storage/day, bandwidth at peak, QPS, and working-set size. The po...