google-design-doclisted

# google-design-doc Produces a **Google-style engineering design doc**: an informal, prose-first document an engineer writes *before* building, to think through a design and get a team to agree on it. Its center of gravity is the **trade-off** — it does not just describe the chosen design, it shows the alternatives that were weighed and says plainly why each was rejected. A design doc captures *declarative design knowledge and its rationale*; it is not a step-by-step procedure and not a product requirements list. This genre follows the widely-published Google pattern (informal tone, trade-off-driven, reviewer-oriented). It is a convention, not a schema — keep the voice conversational and let the design dictate which optional subsections appear. ## Pattern (industry: Google engineering design doc) 1. **Context and Scope** — the background and the problem. What exists today, why it is insufficient, and the boundary of what this doc covers. Orient a reader who has not been in the hallway conversations. 2. **Goals and Non-Goals** — bullet the outcomes that define success, then explicitly bullet what is *out of scope*. Non-goals are not optional; they are how the doc bounds the design and pre-empts scope creep in review. 3. **The Design / Overview** — the proposed approach in prose, then the concrete surfaces it touches: **APIs** (signatures/contracts), **data storage / schema** (tables, keys, indexes, retention), and the **key flows** (the request/data pa