└── README.md /README.md: -------------------------------------------------------------------------------- 1 | # ml-design-doc 2 | 3 | A template for design docs for machine learning systems based on this [post](https://eugeneyan.com/writing/ml-design-docs/). 4 | 5 | Note: This template is a guideline / checklist and is **not meant to be exhaustive**. The intent of the design doc is to help you think better (about the problem and design) and get feedback. Adopt whichever sections—and add new sections—to meet this goal. View other templates, examples [here](#other-templates-examples-etc). 6 | 7 | --- 8 | ## 1. Overview 9 | 10 | A summary of the doc's purpose, problem, solution, and desired outcome, usually in 3-5 sentences. 11 | 12 | ## 2. Motivation 13 | Why the problem is important to solve, and why now. 14 | 15 | ## 3. Success metrics 16 | Usually framed as business goals, such as increased customer engagement (e.g., CTR, DAU), revenue, or reduced cost. 17 | 18 | ## 4. Requirements & Constraints 19 | Functional requirements are those that should be met to ship the project. They should be described in terms of the customer perspective and benefit. (See [this](https://eugeneyan.com/writing/ml-design-docs/#the-why-and-what-of-design-docs) for more details.) 20 | 21 | Non-functional/technical requirements are those that define system quality and how the system should be implemented. These include performance (throughput, latency, error rates), cost (infra cost, ops effort), security, data privacy, etc. 22 | 23 | Constraints can come in the form of non-functional requirements (e.g., cost below $`x` a month, p99 latency < `y`ms) 24 | 25 | ### 4.1 What's in-scope & out-of-scope? 26 | Some problems are too big to solve all at once. Be clear about what's out of scope. 27 | 28 | ## 5. Methodology 29 | 30 | ### 5.1. Problem statement 31 | 32 | How will you frame the problem? For example, fraud detection can be framed as an unsupervised (outlier detection, graph cluster) or supervised problem (e.g., classification). 33 | 34 | ### 5.2. Data 35 | 36 | What data will you use to train your model? What input data is needed during serving? 37 | 38 | ### 5.3. Techniques 39 | 40 | What machine learning techniques will you use? How will you clean and prepare the data (e.g., excluding outliers) and create features? 41 | 42 | ### 5.4. Experimentation & Validation 43 | 44 | How will you validate your approach offline? What offline evaluation metrics will you use? 45 | 46 | If you're A/B testing, how will you assign treatment and control (e.g., customer vs. session-based) and what metrics will you measure? What are the success and [guardrail](https://medium.com/airbnb-engineering/designing-experimentation-guardrails-ed6a976ec669) metrics? 47 | 48 | ### 5.5. Human-in-the-loop 49 | 50 | How will you incorporate human intervention into your ML system (e.g., product/customer exclusion lists)? 51 | 52 | ## 6. Implementation 53 | 54 | ### 6.1. High-level design 55 | 56 | ![](https://upload.wikimedia.org/wikipedia/commons/thumb/2/2e/Data-flow-diagram-example.svg/1280px-Data-flow-diagram-example.svg.png) 57 | 58 | Start by providing a big-picture view. [System-context diagrams](https://en.wikipedia.org/wiki/System_context_diagram) and [data-flow diagrams](https://en.wikipedia.org/wiki/Data-flow_diagram) work well. 59 | 60 | ### 6.2. Infra 61 | 62 | How will you host your system? On-premise, cloud, or hybrid? This will define the rest of this section 63 | 64 | ### 6.3. Performance (Throughput, Latency) 65 | 66 | How will your system meet the throughput and latency requirements? Will it scale vertically or horizontally? 67 | 68 | ### 6.4. Security 69 | 70 | How will your system/application authenticate users and incoming requests? If it's publicly accessible, will it be behind a firewall? 71 | 72 | ### 6.5. Data privacy 73 | 74 | How will you ensure the privacy of customer data? Will your system be compliant with data retention and deletion policies (e.g., [GDPR](https://gdpr.eu/what-is-gdpr/))? 75 | 76 | ### 6.6. Monitoring & Alarms 77 | 78 | How will you log events in your system? What metrics will you monitor and how? Will you have alarms if a metric breaches a threshold or something else goes wrong? 79 | 80 | ### 6.7. Cost 81 | How much will it cost to build and operate your system? Share estimated monthly costs (e.g., EC2 instances, Lambda, etc.) 82 | 83 | ### 6.8. Integration points 84 | 85 | How will your system integrate with upstream data and downstream users? 86 | 87 | ### 6.9. Risks & Uncertainties 88 | 89 | Risks are the known unknowns; uncertainties are the unknown unknows. What worries you and you would like others to review? 90 | 91 | ## 7. Appendix 92 | 93 | ### 7.1. Alternatives 94 | 95 | What alternatives did you consider and exclude? List pros and cons of each alternative and the rationale for your decision. 96 | 97 | ### 7.2. Experiment Results 98 | 99 | Share any results of offline experiments that you conducted. 100 | 101 | ### 7.3. Performance benchmarks 102 | 103 | Share any performance benchmarks you ran (e.g., throughput vs. latency vs. instance size/count). 104 | 105 | ### 7.4. Milestones & Timeline 106 | 107 | What are the key milestones for this system and the estimated timeline? 108 | 109 | ### 7.5. Glossary 110 | 111 | Define and link to business or technical terms. 112 | 113 | ### 7.6. References 114 | 115 | Add references that you might have consulted for your methodology. 116 | 117 | --- 118 | ## Other templates, examples, etc 119 | - [A Software Design Doc](https://www.industrialempathy.com/posts/design-doc-a-design-doc/) `Google` 120 | - [Design Docs at Google](https://www.industrialempathy.com/posts/design-docs-at-google/) `Google` 121 | - [Product Spec of Emoji Reactions on Twitter Messages](https://docs.google.com/document/d/1sUX-sm5qZ474PCQQUpvdi3lvvmWPluqHOyfXz3xKL2M/edit#heading=h.554u12gw2xpd) `Twitter` 122 | - [Design Docs, Markdown, and Git](https://caitiem.com/2020/03/29/design-docs-markdown-and-git/) `Microsoft` 123 | - [Technical Decision-Making and Alignment in a Remote Culture](https://multithreaded.stitchfix.com/blog/2020/12/07/remote-decision-making/) `Stitchfix` 124 | - [Design Documents for Chromium](https://www.chromium.org/developers/design-documents) `Chromium` 125 | - [PRD Template](https://works.hashicorp.com/articles/prd-template) and [RFC Template](https://works.hashicorp.com/articles/rfc-template) (example RFC: [Manager Charter](https://works.hashicorp.com/articles/manager-charter)) `HashiCorp` 126 | - [Pitch for To-Do Groups and Group Notifications](https://basecamp.com/shapeup/1.5-chapter-06#examples) `Basecamp` 127 | - [The Anatomy of a 6-pager](https://writingcooperative.com/the-anatomy-of-an-amazon-6-pager-fc79f31a41c9) and an [example](https://docs.google.com/document/d/1LPh1LWx1z67YFo67DENYUGBaoKk39dtX7rWAeQHXzhg/edit) `Amazon` 128 | - [Writing for Distributed Teams](http://veekaybee.github.io/2021/07/17/p2s/), [How P2 Changed Automattic](https://ma.tt/2009/05/how-p2-changed-automattic/) `Automattic` 129 | - [Writing Technical Design Docs](https://medium.com/machine-words/writing-technical-design-docs-71f446e42f2e), [Writing Technical Design Docs, Revisited](https://medium.com/machine-words/writing-technical-design-docs-revisited-850d36570ec) `AWS` 130 | - [How to write a good software design doc](https://www.freecodecamp.org/news/how-to-write-a-good-software-design-document-66fcf019569c/) `Plaid` 131 | 132 | Contributions [welcome](https://github.com/eugeneyan/ml-design-docs/pulls)! 133 | --------------------------------------------------------------------------------