A template for design docs for machine learning systems based on this post.

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.

A summary of the doc's purpose, problem, solution, and desired outcome, usually in 3-5 sentences.

Why the problem is important to solve, and why now.

Usually framed as business goals, such as increased customer engagement (e.g., CTR, DAU), revenue, or reduced cost.

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 for more details.)

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.

Constraints can come in the form of non-functional requirements (e.g., cost below $x a month, p99 latency < yms)

Some problems are too big to solve all at once. Be clear about what's out of scope.

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).

What data will you use to train your model? What input data is needed during serving?

What machine learning techniques will you use? How will you clean and prepare the data (e.g., excluding outliers) and create features?

How will you validate your approach offline? What offline evaluation metrics will you use?

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 metrics?

How will you incorporate human intervention into your ML system (e.g., product/customer exclusion lists)?

Start by providing a big-picture view. System-context diagrams and data-flow diagrams work well.

How will you host your system? On-premise, cloud, or hybrid? This will define the rest of this section

How will your system meet the throughput and latency requirements? Will it scale vertically or horizontally?

How will your system/application authenticate users and incoming requests? If it's publicly accessible, will it be behind a firewall?

How will you ensure the privacy of customer data? Will your system be compliant with data retention and deletion policies (e.g., GDPR)?

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?

How much will it cost to build and operate your system? Share estimated monthly costs (e.g., EC2 instances, Lambda, etc.)

How will your system integrate with upstream data and downstream users?

Risks are the known unknowns; uncertainties are the unknown unknows. What worries you and you would like others to review?

What alternatives did you consider and exclude? List pros and cons of each alternative and the rationale for your decision.

Share any results of offline experiments that you conducted.

Share any performance benchmarks you ran (e.g., throughput vs. latency vs. instance size/count).

What are the key milestones for this system and the estimated timeline?

Define and link to business or technical terms.

Add references that you might have consulted for your methodology.

• A Software Design Doc Google
• Design Docs at Google Google
• Product Spec of Emoji Reactions on Twitter Messages Twitter
• Design Docs, Markdown, and Git Microsoft
• Technical Decision-Making and Alignment in a Remote Culture Stitchfix
• Design Documents for Chromium Chromium
• PRD Template and RFC Template (example RFC: Manager Charter) HashiCorp
• Pitch for To-Do Groups and Group Notifications Basecamp
• The Anatomy of a 6-pager and an example Amazon
• Writing for Distributed Teams, How P2 Changed Automattic Automattic
• Writing Technical Design Docs, Writing Technical Design Docs, Revisited AWS
• How to write a good software design doc Plaid

Contributions welcome!