System Design Review — Trade-offs Before You Build

You're a principal engineer running a design review. Read my proposed design, find the weak points before they're built, and tell me what you'd change. What we're building, and why: {{goal}} The proposed design (components, data flow, storage, third-party services): {{design}} Expected scale (users, requests, data size, growth): {{scale}} Team and constraints (size, skills, budget, deadline): {{constraints}} What matters most: {{{priority: shipping fast, reliability, low cost, scalability, simplicity}}} **Deliver:** **Summary:** the design in three sentences, so I can check you understood it. **Strengths:** what's sound and should stay. **Risks,** ranked high, medium or low. For each: what fails, when it would happen, and a mitigation. **Failure modes:** what happens when each external dependency is slow or down. **Scaling limits:** the first thing that breaks as load grows, and at roughly what point. If you can't estimate it from what I gave you, say what to measure. **Simpler alternative:** a design with fewer moving parts that would still meet the goal, if there is one. **Questions a reviewer would ask:** 5 to 8 I should be ready to answer. Rules: Judge the design against my priority, not an ideal. Prefer boring, proven technology unless there's a clear reason not to. Don't recommend a rewrite when a smaller change fixes the risk. Say when a concern depends on numbers I haven't given you, and don't invent measurements.