system-design-reviewlisted

# System design review The goal is not a diagram. The goal is to find, before implementation, the two or three decisions that are expensive to reverse — and to be honest about failure. ## Order of attack Work in this order. Most bad designs go wrong at step 1 or 2 and never recover by adding boxes. ### 1. Constraints and numbers first Refuse to design without rough numbers. Ask, estimate, or state the assumption: - Read and write rates: steady, and peak-to-average ratio. - Data volume today, and growth per month. - Latency budget, at p99 not average, and who set it. - Consistency requirement: what breaks if a reader sees stale data for 5s? - Blast radius tolerance: what fraction of users may this outage affect? An order-of-magnitude estimate changes the design; precision rarely does. 100 rps and 100k rps are different systems. 100 rps and 300 rps are the same system. ### 2. Data model and ownership - One writer per piece of data. Two services writing the same table is not a design, it is a future incident. - What is the source of truth, and what is a derived copy? Every derived copy needs a rebuild path. - What must be transactional *together*? That boundary is your aggregate — and it usually dictates the service boundary, not the org chart. ### 3. Flow, sync vs async For each interaction, ask: does the caller need the result to proceed? - **Yes** → synchronous. Then you own its latency and its failure. - **No** → asynchronous. Then you own delivery semantic