distributed-system-designlisted

# Forces-Driven Distributed System Design Design from **forces**, not from a catalog: `requirements -> forces -> estimates -> simplest topology -> contracts -> failure model -> evolution -> proof` Every component, edge, and pattern is **earned** by a named requirement or constraint. The strongest design is the simplest topology whose contracts survive the stated load, failures, and evolution. ## Choose the depth Begin at the requested decision and follow only branches that can change its verdict or make the result unsafe. Reuse supplied evidence and settled decisions. - **End-to-end design, readiness, migration, or material guarantee change:** trace the full in-scope chain from forces through proof. - **Narrow review, diagnosis, or correction:** stay on the affected journey and its decision-changing dependencies; leave unrelated capacity, topology, migration, and failure work out of scope. - **Unmet need for distribution:** keep the current deployable, store, or synchronous path and name the measurable condition that would justify the next boundary. Preserve unresolved inputs as labelled assumptions, variables, or gaps. The sections below are a causal map, not mandatory report headings. ## Authority and evidence For review, diagnosis, design, or planning, inspect available requirements, code, schemas, diagrams, telemetry, incidents, and deployment artifacts while preserving state. For build or change requests, make in-scope local changes and run non-destructive valid