Engineering Design Reviews

# <Team name>, <Project Name>

Engineering Design Review

* Authors:
* Date:
* Required reviewers: <consider review from people outside of your team/org>
* Status: <draft|ready for review|approved>

<!--
  Brief description of the problem being solved and the approach being suggested.
  Focus on the external behavior of the system (APIs, SLO requirements, etc),
  and for larger initiatives, outline the system design sufficiently such that
  parallel streams of work can make progress independently.
-->

## Context, scope, and history

<!--
  Establish context for the system under review and the changes you’re considering:

  * what does the audience need to know to better understand the changes that follow?
-->

## Goals and non-goals

<!--
  What is a measurable definition of success? (e.g. Reduce p95 response time to <100ms).
  What are you explicitly not solving with this approach?
-->

## Design overview

<!--
  Details of your prospective solution.
  This should be comprehensive, assume your audience is technical but may not be
  intimately familiar with the systems under consideration.

  Where appropriate, include system diagrams, API definitions, pseudo-code,
  etc to concretize your design; provide your audience with a sense of the
  technical underpinnings of your solution.
-->

## Dependencies

<!--
  Enumerate system and if relevant, organizational dependencies.
  It is very likely that at this stage, not all dependencies will be known,
  and/or some decision points around dependencies may remain.
-->

## Milestones

<!--
  How will you approach the solution?
  What are notable, significant achievements that we'd consider a strong
  indicator of progress. Are there any go/no-go decision points?
-->

## COGS

<!--
  What does it cost to operate your system presently and how do these changes impact your COGS?
  How does the cost change with additional scale?
  What model did you use to derive these costs?
-->

## Privacy and security concerns

<!--
  What does your system potentially expose and what are you doing to mitigate the impact?
  Will a security review be required before moving forward with implementation?
-->

## Risks

<!--
  What are the system and organizational risks you’re assuming as part of this solution?
-->

## Alternatives considered

<!--
  What solutions weren’t appropriate and why?
-->

## Supporting material

<!--
  Include any additional references or related documentation.
-->

## [YOUR PROJECT/LAUNCH NAME] Production Readiness Review

### General

<!--
  What does this service/feature do?
  Feel free to summarize, link to docs, or reference anything else that provides
  context for those unfamiliar with the service/feature.
  What are some of the larger/more important PRs related to this service/feature?
-->

### Availability

<!--
  Who is the product owner responsible for this service?
  What dependencies does this feature/service have?
  What are the reasons for our choices in technology?
  What are the failure cases that we might expect?
  How can we ensure partial failure over full failure?
  Are any new hosts or dependencies introduced as part of this launch?
  How should physical resources be allocated to minimize the impact of failure?
  What is the rollout plan (check list here or in a linked issue.)
  Do we have any fallback mechanisms in place?
  How will this feature or service behave when the site is in maintenance mode?
-->

### Performance

<!--
  If this service is replacing a current service how does it compare against its predecessor?
  Will shipping this feature cause additional load for any other services?
  How can we test the performance of this feature prior to launch?
  Do we have metrics being recorded so we can measure performance improvements/regressions?
  What happens if people add thousands of relations for your new feature?
  Does the feature have any N+1?
  What limits have be put in place?
  What is the rationale behind them?
-->

### Monitoring

<!--
  What metrics (graphs and/or dashboards) are there to monitor this feature/service?
  Does the service have a health check endpoint (`/_ping`, etc) for external monitoring?
  Who will receive alerts/pages for this service?
  Does your service receive http requests?
  If so, does it log and add the `X-Request-Id` HTTP header to logs?
-->

### Documentation

<!--
  What documentation do we have to hand to ops so they can support this in production?
  Have playbooks been created?
-->

### Growth/Long Term

<!--
  What team will own/maintain this feature/service in the long term?
  What is the expected growth of this feature/service over time?
  Do we understand how the consumption of resources (db rows, disk space,
  memory and CPU consumption) will increase over time?
-->

### Enterprise

<!--
  What is the plan for including the feature/service in Enterprise?
  Will anything work differently for this feature/service in Enterprise than it does in dotcom?
  Are there automatic and/or manual tests for Enterprise for this feature/service?
  How will any long-running or complicated data migration be handled on Enterprise?
  How will the resource growth of this feature/service be managed within Enterprise?
  If this feature/service will not be included in Enterprise has it been disabled appropriately?
-->

### Security

<!--
  Does this service/feature need an application security review?
  Are all security relevant events being logged to provide an audit trail of user activity?
-->

### Legal

<!--
  Is this service/feature compatible with our current privacy policy?
-->

### Docs

<!--
  Does this service requires new or updated documentation?
-->

### Support

<!--
  Has the support team been made aware of this new service/feature and its release date?
-->