# System Design Questionnaire A collection of questions worth answering before building a new system, service, or product. With a short list at the end. **How to use it:** Timebox the first pass to 60–90 minutes. Write the answers down. Run it three times: before design, before build, before launch. If the answers don't change between passes, check if you missed to capture a learning. A question you can't answer is a finding, not a failure. Note it as an action item and move on. --- ## 1. Purpose 1. What problem is this addressing? 2. Whose problem is it? 3. Who is the user, and what is the one job they hire us to do? 4. What do they do today instead? Why isn't that good enough? 5. What's the cheapest thing that would mostly work — buy it, extend something existing, a spreadsheet? 6. What is this explicitly **not** for? 7. What does success look like as a number, by when? 8. What outcome would make us shut it down? > Red flag: success is described as "shipped." --- ## 2. Risk and sequencing 1. Which decisions here are one-way doors? Usually: the data model, external contracts, trust boundaries, and (public) identifiers. Go slow on those and fast on everything else. 2. What's the riskiest assumption, and what's the cheapest experiment that tests it this week? 3. What's the smallest version that delivers real value to a real user? 4. What did we decide and why — including the options we rejected? Write it down; you'll be asked. --- ## 3. Shape — the expensive-to-undo parts ### Data 1. What are the core entities? Name them all. 2. For each: who is the source of truth? Created how, changed by whom, kept how long? 3. What's the hardest access pattern we have to serve well? 4. What data is regulated, sensitive, or subject to deletion/retention requirements? 5. Where does state live, and what happens when the same work happens twice? ### Boundaries 1. What interfaces will others depend on? Who consumes them today, and who might tomorrow? 2. How do we change those interfaces without breaking consumers? 3. What do we depend on? For each dependency: what happens when it's slow, wrong, or gone? 4. If state is lost, how much can we lose and how long can recovery take? (RPO/RTO) ### Load 1. How many objects exist, how large are they on the mean, and how fast do they grow (in a year)? 2. What are average and peak read/write rates? 3. How much concurrency do we expect? 4. Which number, if it were 10x, would break the design? Which numbers don't matter at all? > Red flag: "we don't know, a lot." That's not a constraint, and you can't design against it. --- ## 4. Under stress 1. Name the three most likely ways this fails. For each: who notices, how quickly, and how far does the damage spread? 2. Name at least three ways the system can appear healthy while producing a bad outcome. How will we notice before our users do? 3. When forced to choose: correct-but-unavailable, or available-but-stale? Answer per operation, not for the whole system. 4. What's the worst thing a bug or an attacker could cause here? 5. Which data would hurt most to leak, lose, or corrupt? 6. Who's allowed to do what, and where exactly is that enforced? 7. Where does data or control cross from one security domain to another — for example user→service, service→service, tenant→shared system, or system→third party? What information/credential crosses such a boundary, and how is it authenticated, authorized, and validated? 8. What counts as acceptable degradation, as opposed to being down? --- ## 5. Life after launch 1. How would we know right now whether users are getting the service we promised? What SLOs and signals tell us the system is working correctly? 2. What alerts exist, and who gets woken up by the? 3. How do we deploy, and how do we undo? How long does a rollback take? 4. How do we migrate, backfill, or repair data? (Ask this *before* the schema is fixed.) 5. Who owns this in two years? What does it cost — in infrastructure and in human attention? --- ## The refine loop - **Pass 1 — before design.** Sections 1, 2. Goal: is this worth building, and what's the one-way door? - **Pass 2 — before build.** Sections 3, 4. Goal: commit to the shape, on purpose. - **Pass 3 — before launch.** Section 5, then re-read Section 1. Goal: can we run it, and are we still solving the thing we started with? Standing rule: If answering one of these requires another team, that dependency is part of the design. Record the owner and unresolved decision rather than silently assuming an answer. --- ## The minimal version If you answer nothing else, answer these: 1. Purpose: What breaks if we don't build this? 2. Users: Who uses it, and what single job does it do for them? 3. Data Ownership: What are the nouns (core entities), and who owns the truth about each one? 4. Load Management: What's the load — volume (bytes, with growth rate), rate (reads/writes $s^{-1}$}, latency (per quartile, in ms), availability (%, with a definition of *down*), consistency (requirements), durability (requirements)? 5. Failure Modes: How can it fail, degrade, or silently produce a wrong result — and who notices first? 6. Risky Conjectures: What's the riskiest assumption, and what's the cheapest way to find out if we're wrong? 7. Architectural Planning: What changes are we most likely to need in the next year?