News for hackers. Stuff that matters.
Re:Things to say when you're losing a technical argument (2001) by nanomonkey on Saturday November 06, 2021 @01:50AM (#29127856)
[Design Doc Template]

* Background

Background on the problem we’re solving.

* Design Goals

Requirements and goals of the project. This should also include numbers like traffic assumptions, usage, uptime requirements, etc.

* Other Proposals

Options that were looked at, but we evaluated that weren’t going to work

1. Option 1

2. Option 2

* Solution Summary

Summary of the solution in a paragraph or two.

* Solution Details

Details of the solution...feel free to add/remove sections that make sense, some starter ones are below.

* System diagram

Diagram of all the binaries, databases and 3rd party services that this system touches

* Wire frames

Any wireframes for the UI if this has a frontend component?

* Code

Where is the code going to go? Does this touch any common repos? Any new repos being created?

* Testing

What kind of testing is going to be done. Unit tests, regression tests, etc.

* Scaling

What aspects of traffic do we need to think about for scaling. If the traffic goes 10x, we ok? could the database grow 10x and cause issues?

* Operation details

Details that the operations team might want to know like location of binaries, monitoring to be setup, oncall, etc

* Internationalization

Do we need to think about spanish?

* Tradeoffs made

Write out the big tradeoffs made

There are no comments on this comment yet.