# Review and Improve a Flawed Design Document You are given a design document for a system that has important omissions or unsafe assumptions. Review it, identify the highest-risk defects, and propose a coherent revision. Explain how you separate requirement gaps, correctness failures, scalability limits, and presentation problems. ### Constraints & Assumptions - The supplied document and interviewer clarifications define the concrete system; do not invent missing product requirements silently. - Time is limited, so prioritize issues by impact and likelihood rather than rewriting every paragraph. - Preserve sound parts of the design and make changed assumptions explicit. - A revised diagram or flow is welcome, but every new component needs a reason. ### Clarifying Questions to Ask - Which requirements and service-level objectives are fixed? - What scale, traffic shape, data sensitivity, and failure model should the design support? - Is the task primarily review, redesign, or risk assessment? - Which operational or organizational constraints may not change? - How should conflicting requirements be resolved? ### Hints - Begin with the document's claimed invariants and trace one critical operation end to end. - Look for behavior during retries, partial failure, concurrency, and recovery. - Rank findings before discussing remedies. ### What a Strong Answer Covers - A restatement of goals, non-goals, assumptions, and measurable requirements. - A risk-ranked review with evidence tied to specific flows or invariants. - Data ownership, consistency, idempotency, failure recovery, capacity, security, and observability. - A revised architecture that fixes root causes without unnecessary components. - Migration, rollout, validation, alternatives, and explicit residual risks. - Clear distinction between a design defect and a document that merely fails to explain a sound choice. ### Follow-up Questions 1. Which single issue would block approval, and what evidence would change your judgment? 2. How would you test the most important invariant before rollout? 3. What is the smallest safe revision if the launch date cannot move? 4. Which suggested improvement adds the greatest operational complexity?