A product manager walks into the sprint planning meeting and says: “We need to support ten times the current user load by Q3.” Three engineers hear three different things. One thinks about database indexing. One thinks about horizontal scaling. One thinks about caching. All three are correct — and none of them has enough information to start building.
The gap between a product requirement and an architecture decision is not technical. It is analytical. Before a single component is chosen, the system’s behaviour must be characterised numerically: how many reads per second, how many writes, how much data, how consistent, how available, how fast. Requirements without numbers are not actionable. This chapter closes that gap with a systematic translation process.
Given a product description, produce a quantified characterisation of the system’s demands: read and write QPS, storage volume, bandwidth, consistency requirements, and latency targets. From this characterisation, determine the architectural constraints that eliminate whole categories of solutions and narrow the design space to a tractable set of choices.
The challenge is that product requirements are stated in user terms (“users can post and read messages”) and must be translated into engineering terms (“1,200 write QPS, 120,000 read QPS, 180 TB storage over five years”) before any meaningful architecture work can begin.