I like the discipline of writing these out for myself, I like reviewing them, and I like being able to look back on them for my own past projects as a way to quickly warm my mental cache.
I like the discipline of writing these out for myself, I like reviewing them, and I like being able to look back on them for my own past projects as a way to quickly warm my mental cache.
Maybe it's just me, but this sounds quite heavy.
Just let me know what you want to learn, how you hope to use it, and what you've tried in the past.
kthx
* 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
https://web.archive.org/web/20051224054905/http://www.joelon...
If that was helpful, then please donate.