Capstone checklist — a design is done when these all hold

At a glance

Learning objectives

• Apply a nine-point checklist to any design before calling it done
• Run the same checklist against a production platform as an audit
• Identify which checklist item your current design fails, and fix that one

What you need

• Lessons 1–9 completed
• One live design (new or existing) to audit

Steps

1. Check the spine first — reliability, scalability, replication, partitioning, consistency, and batch/stream — if the design cannot say where it stands on the six axes, the rest of the checklist has nothing to stand on. (from ref-ddia )
2. Check the numbers and levers — the Primer's estimation drills and scaling vocabulary (load balancers, caching, sharding) exist so the design's arithmetic and first lever are written down, not implied. (from ref-system-design-primer )
3. Check the reliability contract — the SRE books' SLIs/SLOs/error budgets, incident management, postmortem culture, and capacity planning are the standing items, and each needs an owner and a number before launch. (from ref-sre-google )
4. Check the failure policies — Microsoft's pattern catalogue (retry, circuit breaker, compensating transaction, bulkhead) gives every failure mode a bounded, named response; a design with unhandled failure shapes fails this item. (from ref-cloud-design-patterns )
5. Check the precedent — reference architectures are the closest thing to citable evidence when an answer needs a real-world precedent, so the last checklist item is always a deployed architecture your design can be compared against. (from ref-aws-arch-center )
6. Audit the existing platform with the same list — grounding in best-practice guidance (Well-Architected pillars, data lake patterns) is what the AWS collection exists for, and drift between your platform and the pillars is the audit's finding. (from ref-aws-arch-center )

Check yourself

• Your most recent design passes all nine checklist items with numbers, not adjectives, in the boxes.
• Auditing your production platform surfaces at least one failing item — and you know which lesson teaches its fix.

Worked example

Capstone checklist — a design is done when:
[ ] Tradeoffs named explicitly (reliability vs scalability vs maintainability)
[ ] Numbers estimated (QPS, storage, retention, peak) and written down
[ ] Storage engine chosen with the mechanism reason stated
[ ] Scaling levers named (LB, cache, shard) and the FIRST lever identified
[ ] SLIs + SLO + error budget defined for the top user-visible property
[ ] One resilience pattern per failure mode (retry, breaker, bulkhead...)
[ ] Capacity plan exists, with a date it gets re-derived
[ ] Failure drill written: what breaks first, who is paged, what budget allows
[ ] A deployed reference architecture cited as precedent

Sourced from

• Designing Data-Intensive Applications (O'Reilly)
• The System Design Primer
• Google SRE Books
• Azure Cloud Design Patterns
• AWS Architecture Center

Security scan

Last sweep 2026-10-24: 0 finding(s), 0 marked as examples.

Common gotchas

• A checklist item with an adjective instead of a number is not checked — rewrite it.
• The checklist audits designs, not people — a failing item is a finding, not a verdict.
• Precedent is the last item for a reason — it checks the others, it cannot replace them.

Production considerations

• Pin the checklist in the design-doc template so it runs by default.
• Re-run the audit after major growth events — the checklist is a snapshot, load is a movie.

Diagram

capstone checklist
   |
   |- 1 tradeoffs named (reliability vs scalability vs maintainability)
   |- 2 numbers estimated (QPS, storage, retention, peak)
   |- 3 storage chosen by mechanism (repl | part | consistency)
   |- 4 first scaling lever named (LB | cache | shard)
   |- 5 SLI + SLO + error budget defined
   |- 6 one resilience pattern per failure mode
   |- 7 capacity plan exists with a revisit date
   |- 8 incident drill + postmortem loop defined
   |- 9 deployed precedent cited
   |
    --> all nine, or the design is not done

Registry stats