Five system design templates

What do the templates cover?

Five documents: a design doc, a capacity estimate, an incident review, an architecture decision record and a migration plan. Each one is a filled example alongside a blank, so you can see what a good answer looks like before writing your own.

They exist because the same question kept arriving by email: what should this document contain. Every template is built from the structures that hold up in review at companies with a functioning design process, stripped of the process theatre that comes with them.

1. 01

   Design doc

   The structure a design doc needs to survive review: problem statement, constraints, the options considered, the one chosen and why, and the failure modes accepted. Includes the prompts that force an author to state a trade-off rather than describe a solution.

2. 02

   Capacity estimate

   Back-of-envelope sizing for reads, writes, storage growth and peak-to-average ratio, with the arithmetic laid out so a reviewer can check your assumptions instead of your multiplication.

3. 03

   Incident review

   A blameless post-mortem format built around a timeline, contributing factors and detection gap. Structured so the action items attach to a specific step in the timeline.

4. 04

   Architecture decision record

   A one-page ADR with context, decision, status and consequences. Short enough that people actually write them, structured enough that the next team understands why the choice was made.

5. 05

   Migration plan

   Dual-write and backfill sequencing, the cutover checklist, the rollback trigger, and the verification step most migration plans leave implicit until the night of.

How do you get them?

The templates ship with Premium, alongside the full archive, source links for every edition and comment access. Subscribing takes you to Substack, where billing and the archive live.

Your company probably has a learning budget for this. Here is the email to send.