System Design Review Checklist and Scoring Rubric Template

Design review checklist in 13 areas, evidence-based scoring rubric, weighted score, red flags, findings register, decision record, 45-minute interview rubric

System DesignFullsystem design review checklist mathUpdated Oct 22, 2026

Open in editorDownload .md

How to use: Use it when you review someone else's system design or run a system design interview. Agree the area weights and send the checklist to the author before the meeting, then score only on evidence. The main pitfall is scoring confidence instead of evidence, or redesigning the system in the meeting instead of recording findings.

Preview

System Design Review Checklist: [System or design name]

Checklist and scoring rubric for reviewing a system design, for design reviewers in engineering organisations and for interviewers running a system design interview. It covers thirteen areas: requirements and scope, estimation, API, data model and access patterns, consistency per write path, single points of failure, scalability, failure modes, security and privacy, operations and SLOs, cost, migration and rollout, and evolvability. Each area is scored on a four-level rubric defined by observable evidence, red flags block approval, and the review ends with a recorded decision. Section 8 gives a 45-minute interview variant. The checklist draws on common industry practice and on public methods such as the SEI Architecture Tradeoff Analysis Method (ATAM) and the AWS Well-Architected Framework. Replace every [bracketed] value and every row marked Example.

Document control

Field	Value
Document ID	[SDR-2026-001]
Version	[0.1]
Status	[Draft / In review / Decision recorded]
Owner (lead reviewer)	[@lead-reviewer]
Approvers / reviewers	[@reviewer-1], [@reviewer-2], [@security-reviewer]
Last updated	YYYY-MM-DD
Classification	[Internal]
Design under review	[Title], [document ID], [version or commit]
Design author(s)	[@author]
Review mode	[Design review / Interview (section 8)]
Review date	YYYY-MM-DD

Approvals

Role	Name	Decision	Date
Lead reviewer	[@name]	[Approved / Approved with conditions / Changes required]	YYYY-MM-DD
Security reviewer	[@name]	[Decision]	YYYY-MM-DD
Operations / SRE reviewer	[@name]	[Decision]	YYYY-MM-DD
Design owner (acknowledges findings)	[@name]	[Acknowledged]	YYYY-MM-DD

Revision history

Version	Date	Author	Change summary
0.1	YYYY-MM-DD	[@name]	Pre-read scores
0.2	YYYY-MM-DD	[@name]	Example: Scores after review meeting; findings SDR-F-001 to SDR-F-006
1.0	YYYY-MM-DD	[@name]	Example: Decision recorded: approved with conditions

Review scope and inputs
Scoring rubric
Checklist by area
Score summary
Red flags
Findings register
Review record and decision
Interview mode: 45-minute rubric
Glossary and references

1. Review scope and inputs

Item	Value
Decision this review supports	[Example: Start implementation of the payment ledger in Q1]
In scope	[Example: Write path, ledger storage, reconciliation, rollout]
Out of scope	[Example: UI, pricing, vendor contract]
Inputs received	[Design document link, ADRs, load test results, threat model]
Pre-read deadline	YYYY-MM-DD
Reviewers and focus	[Example: @a data model, @b reliability, @c security]

Rules for this review:

Reviewers score each area independently before the meeting, then agree on one score per area in the meeting.
A reviewer who cannot find evidence for a check marks it "No evidence" rather than guessing.
Checks that do not apply are marked N/A with a one-line reason; an N/A area is removed from the weighted total (section 4).

2. Scoring rubric

Every area in section 3 is scored on one scale:

Level	Name	Observable evidence
0	Missing	The area is not addressed in the document or the review
1	Asserted	The area is mentioned, but claims have no reasoning, numbers or alternatives ("it will scale", "we use retries")
2	Reasoned	Claims are backed by numbers, a named mechanism and at least one rejected alternative with the reason
3	Evidenced	Level 2 plus evidence that the claim holds: a prototype, load test, failure drill, measurement from a comparable system, or a cited and applicable reference

Area-specific anchors, so reviewers calibrate the same way:

Area	Level 1 looks like	Level 3 looks like
Estimation	"Millions of users"	Inputs, formulas, results and the design consequence of each number, checked against measured traffic
Consistency	"Strongly consistent database"	Each write path named with its guarantee, isolation level and the anomaly it prevents, with a test that shows it
Failure modes	"Highly available"	Failure table with detection, blast radius, mitigation and RTO, and a game day result for the top two
Security	"Uses TLS and auth"	Threat model with trust boundaries, data classification, and controls traced to threats
Cost	"Should be cheap"	Unit cost model per request or per tenant, with the largest line item and how it scales

3. Checklist by area

3.1 Requirements and scope (A1)

ID	Check	Evidence expected	Notes
SDR-A1-01	Problem and users stated, with the business driver	Problem statement, success metric	[Section ref]
SDR-A1-02	Core functional requirements separate from below-the-line items	Two explicit lists
SDR-A1-03	Non-functional requirements have numbers and a measurement method	Table with target and "measured as"
SDR-A1-04	Assumptions and constraints listed (team, deadline, existing systems)	Assumptions table
SDR-A1-05	Decisions requested from reviewers are explicit	Question list with recommended option

3.2 Estimation (A2)

ID	Check	Evidence expected
SDR-A2-01	Peak rate, not only average, for reads and writes	Peak-to-average factor stated
SDR-A2-02	Storage growth over the planning horizon, with replication	Formula and result
SDR-A2-03	Each number ends in a design consequence	"So we ..." sentence per estimate
SDR-A2-04	Orders of magnitude sanity-checked against a known system	Comparison or measurement

See Back-of-Envelope Estimation and Capacity Model Template (system-design/back-of-envelope-estimation).

3.3 API (A3)

ID	Check	Evidence expected
SDR-A3-01	Operations, inputs, outputs and errors defined	API table or schema
SDR-A3-02	Idempotency for retried writes	Idempotency key or natural key semantics
SDR-A3-03	Pagination, limits and rate limits	Stated limits
SDR-A3-04	Versioning and compatibility policy	Versioning rule
SDR-A3-05	Authentication and authorization per operation	Scope or permission per call

3.4 Data model and access patterns (A4)

ID	Check	Evidence expected
SDR-A4-01	Entities and relationships drawn	ER diagram or schema
SDR-A4-02	Access-pattern table: query, key or index, partition key rationale	Table covering every hot query
SDR-A4-03	Hot partitions and skew considered	Named hot keys and mitigation
SDR-A4-04	Store choice justified by access pattern, not habit	Comparison of at least two stores
SDR-A4-05	Retention, deletion and archival defined	Retention table

3.5 Consistency per write path (A5)

ID	Check	Evidence expected
SDR-A5-01	Every write path listed with its consistency guarantee	Table: path, guarantee, mechanism
SDR-A5-02	Multi-step writes have a defined atomicity strategy (transaction, outbox, saga)	Sequence diagram with failure between steps
SDR-A5-03	Read-after-write expectations stated per client	Which reads may be stale and for how long
SDR-A5-04	Concurrency control for contended records	Locking, conditional writes or version checks
SDR-A5-05	Duplicate and out-of-order events handled	Deduplication key, ordering scope

3.6 Single points of failure (A6)

ID	Check	Evidence expected
SDR-A6-01	Every component on the critical path has redundancy or an accepted risk	Component list with redundancy column
SDR-A6-02	Shared dependencies (DNS, identity, secrets, config) identified	Dependency list
SDR-A6-03	Leader or coordinator failover described and timed	Failover mechanism and duration
SDR-A6-04	Human single points (one person who can deploy or recover)	Ownership and runbooks

3.7 Scalability (A7)

ID	Check	Evidence expected
SDR-A7-01	Scaling unit of each component named (replicas, shards, partitions)	Table "scales by"
SDR-A7-02	First bottleneck identified with the load at which it appears	"Limit before redesign"
SDR-A7-03	Behaviour at 10x and at 0.1x discussed	Trade-off row
SDR-A7-04	Latency budget per hop for the main path	Budget table

3.8 Failure modes (A8)

ID	Check	Evidence expected
SDR-A8-01	Failure-mode table: component, failure, detection, blast radius, mitigation, RTO	Table
SDR-A8-02	Timeouts, retries with backoff and jitter, circuit breakers	Values per dependency
SDR-A8-03	Overload behaviour: load shedding, back-pressure, priorities	Mechanism
SDR-A8-04	Fail-open versus fail-closed decided per dependency	Table with rationale
SDR-A8-05	Backup, restore and disaster recovery with RPO and RTO	Targets and test plan

See Resilience and Load Shedding Design Template (system-design/resilience-load-shedding-design).

3.9 Security and privacy (A9)

ID	Check	Evidence expected
SDR-A9-01	Threat model with trust boundaries	Link to threat model
SDR-A9-02	Data classified; personal data minimised and mapped	Data inventory
SDR-A9-03	Authentication and authorization model, including service-to-service	Identity design reference
SDR-A9-04	Secrets, keys and encryption in transit and at rest	Key management description
SDR-A9-05	Abuse cases and rate limits	Abuse table
SDR-A9-06	Audit logging for security-relevant actions	Event list

Run the detailed analysis in Threat Model Template (security/threat-model) and, where the design changes trust boundaries, Zero Trust Architecture Plan Template (security/zero-trust-architecture).

3.10 Operations and SLOs (A10)

ID	Check	Evidence expected
SDR-A10-01	SLIs and SLOs defined for user-facing behaviour	SLO table
SDR-A10-02	Dashboards and alerts tied to SLOs, not only to resources	Alert list
SDR-A10-03	Runbooks for the top failure modes	Runbook links
SDR-A10-04	Deployment strategy (canary, blue-green) and rollback time	Deploy plan
SDR-A10-05	On-call ownership and escalation	Team and rotation

3.11 Cost (A11)

ID	Check	Evidence expected
SDR-A11-01	Cost estimate by component	Cost table
SDR-A11-02	Unit economics (cost per request, per user or per tenant)	Formula
SDR-A11-03	Largest cost driver and how it scales	Named driver

3.12 Migration and rollout (A12)

ID	Check	Evidence expected
SDR-A12-01	Migration plan for existing data and clients	Backfill, dual-write or dual-read plan
SDR-A12-02	Milestones with exit criteria	Milestone table
SDR-A12-03	Feature flags and rollback for each step	Rollback per step
SDR-A12-04	Verification during migration (shadow traffic, diff reports)	Method

3.13 Evolvability (A13)

ID	Check	Evidence expected
SDR-A13-01	Decisions recorded as ADRs with revisit triggers	ADR links
SDR-A13-02	Schema and API evolution path	Compatibility rules
SDR-A13-03	Known limits and the next redesign point	Limits table
SDR-A13-04	Fitness functions or automated checks protect key qualities	Check list

See Architecture Fitness Functions Catalogue Template (architecture/fitness-functions).

4. Score summary

The weighted score is

S = \frac{100}{\sum_i w_i} \times \sum_i w_i \times \frac{level_i}{3}

where $w_i$ is the weight of each applicable area and $level_i$ its score from 0 to 3. With all thirteen areas applicable, $\sum_i w_i = 100$ .

Area	Weight	Score (0 to 3)	Weighted (w x score)	Main finding
A1 Requirements and scope	10	Example: 3	30
A2 Estimation	6	Example: 2	12
A3 API	6	Example: 2	12
A4 Data model and access patterns	10	Example: 3	30
A5 Consistency per write path	10	Example: 1	10	SDR-F-001
A6 Single points of failure	8	Example: 2	16
A7 Scalability	8	Example: 2	16
A8 Failure modes	10	Example: 2	20	SDR-F-003
A9 Security and privacy	10	Example: 2	20	SDR-F-002
A10 Operations and SLOs	8	Example: 1	8	SDR-F-004
A11 Cost	4	Example: 2	8
A12 Migration and rollout	6	Example: 2	12
A13 Evolvability	4	Example: 2	8
Total	100		202

Example: $S = 202 / 3 \approx 67$ .

Decision bands (Example, agree locally; apply the first row that matches, from the top):

Condition	Outcome
Any blocking red flag (section 5)	Changes required, whatever the score
Any area weighted 10 scored 0	Changes required
$S \ge 75$ and no area below 2	Approved
$S \ge 60$ and none of the rows above apply	Approved with conditions: each area below 2 gets a finding with a due date
$S < 60$	Changes required

In the Example, the score is 67 and two areas are at level 1, so the outcome is "approved with conditions".

5. Red flags

ID	Red flag	Blocking	Why it matters
RF-01	No numbers anywhere: no load, no data size, no latency target	Yes	Every later decision is unfounded
RF-02	Money, inventory or permissions written without a stated consistency guarantee	Yes	Silent double spend, oversell or exposure
RF-03	Retries on non-idempotent writes	Yes	Duplicates under the most common failure
RF-04	A single component whose loss stops the service with no failover and no accepted risk	Yes	Unplanned full outage
RF-05	Personal or secret data with no classification or owner	Yes	Regulatory and breach exposure
RF-06	No rollback path for a schema or data migration	Yes	Irreversible incident
RF-07	Distributed transactions across services assumed to "just work"	Advisory	Usually a hidden saga with no compensation
RF-08	Cache treated as source of truth without a rebuild path	Advisory	Data loss on eviction or restart
RF-09	Alerts only on CPU and memory, none on user-facing SLIs	Advisory	Outages found by customers
RF-10	Technology chosen before the access patterns were written	Advisory	Store fights the workload
[RF-nn]	[Red flag]	[Yes / Advisory]	[Reason]

6. Findings register

ID	Area	Severity	Finding	Expected evidence to close	Owner	Due	Status
SDR-F-001 (Example)	A5	High	The refund path writes ledger and order tables in two calls without an outbox; a crash between them leaves them inconsistent	Atomicity strategy for refunds and a failure-injection test	[@author]	YYYY-MM-DD	Open
SDR-F-002 (Example)	A9	Medium	Service-to-service calls use a shared static token	Workload identity design or rotation plan	[@author]	YYYY-MM-DD	Open
SDR-F-003 (Example)	A8	Medium	No RTO for the reconciliation job	RTO target and restart test	[@author]	YYYY-MM-DD	Open
SDR-F-004 (Example)	A10	Medium	SLOs defined, but alerts are on host metrics only	Burn-rate alerts on the two main SLOs	[@sre]	YYYY-MM-DD	Open
[SDR-F-nnn]	[Area]	[High / Medium / Low]	[Finding]	[Evidence]	[@owner]	YYYY-MM-DD	[Open / Closed / Accepted]

Severity guide: High blocks launch until closed; Medium must close before general availability; Low is tracked in the backlog. An accepted risk needs an owner who has the authority to accept it and a review date.

7. Review record and decision

7.1 Meeting record

Field	Value
Date and duration	YYYY-MM-DD, [60] min
Attendees	[@names]
Design version reviewed	[Version or commit]
Areas discussed	[Example: A5, A8, A9, A10]
Questions resolved	[Example: Q-02 per-region shares accepted]
Questions deferred	[Example: Q-04 build or adopt, to the architecture board]

7.2 Decision

Field	Value
Outcome	[Approved / Approved with conditions / Changes required]
Weighted score	[Example: 67]
Blocking red flags	[Example: None]
Conditions	[Example: Close SDR-F-001 before implementation of refunds; SDR-F-004 before GA]
Re-review needed	[Example: No; lead reviewer verifies closure]
Decision recorded in	[ADR or board minutes link]

7.3 Re-review triggers

Re-open this review when any of the following happens:

Load or data size estimates change by more than [2x].
A write path changes its consistency mechanism.
A new trust boundary or new category of personal data is introduced.
The store, queue or other core technology is replaced.
A High finding is accepted as a risk instead of fixed.

8. Interview mode: 45-minute rubric

8.1 Time plan

Minutes	Phase	What a strong candidate does
0 to 5	Requirements	Asks about users, scale, core features; states below-the-line items
5 to 10	Estimation	Computes two or three numbers and says what each changes
10 to 15	API and data model	Defines the main calls and the access patterns that drive keys
15 to 25	High-level design	Draws the request path end to end and names where state lives
25 to 38	Deep dive	Picks the hardest problem, gives options, chooses with a reason
38 to 45	Wrap-up	Names failure modes, bottlenecks at 10x, and what they would do next

8.2 Dimensions and levels

Score each dimension 1 to 4 on what the candidate showed.

Dimension	1: Insufficient	2: Developing	3: Solid	4: Strong
Problem navigation	Starts drawing without clarifying	Clarifies when prompted	Drives scope, states assumptions	Prioritises scope by impact and revisits it as constraints appear
Estimation and requirements	No numbers	Numbers without consequences	Numbers that shape the design	Spots which estimate the design is most sensitive to
High-level design	Missing components on the main path	Complete but generic	Complete and fitted to the requirements	Simple first, adds parts only when a requirement demands them
Deep dive	Stays at box level	Goes deep only when led	Options, choice and reason for one hard problem	Two hard problems, including consistency or failure, with trade-offs quantified
Trade-offs and communication	Defends one option	Lists alternatives without weighing them	Weighs alternatives against stated requirements	Changes the design when the interviewer changes a constraint, explaining why
Operations and failure	Not mentioned	Mentions monitoring generically	Names failure modes and detection	Blast radius, fail-open or closed, rollout and recovery

8.3 Signal by level (Example calibration)

Target level	Expected profile
[Mid-level engineer]	Mostly 3 on navigation, high-level design and communication; 2 acceptable on deep dive
[Senior engineer]	3 or above on all dimensions; at least one 4
[Staff engineer]	4 on deep dive and trade-offs; 3 or above elsewhere; raises organisational and migration concerns unprompted

8.4 Interview record

Dimension	Score (1 to 4)	Evidence (what the candidate said or drew)
Problem navigation	[n]	[Example: Asked about read/write ratio and global users before drawing]
Estimation and requirements	[n]	[Evidence]
High-level design	[n]	[Evidence]
Deep dive	[n]	[Evidence]
Trade-offs and communication	[n]	[Evidence]
Operations and failure	[n]	[Evidence]
Overall recommendation	[Strong no / No / Yes / Strong yes]	[One paragraph, written before discussing with other interviewers]

Write evidence during or right after the interview. Do not compare notes with other interviewers before submitting your own score.

9. Glossary and references

9.1 Glossary

Term	Meaning
Access pattern	A query the system must serve, with its key, frequency and latency need
Below the line	Requirements explicitly excluded from this design
Blast radius	The users, data or services affected by one failure
RTO / RPO	Recovery time objective / recovery point objective
SLI / SLO	Service level indicator / objective
Red flag	A design defect that blocks or must be tracked before approval
Sensitivity point	A design parameter that strongly affects a quality attribute (ATAM term)

9.2 References

Reference	Use
Kazman, Klein and Clements, "ATAM: Method for Architecture Evaluation", CMU/SEI-2000-TR-004, August 2000	Scenario-based evaluation, risks and sensitivity points
AWS Well-Architected Framework, six pillars (operational excellence, security, reliability, performance efficiency, cost optimization, sustainability)	Cross-check of A6 to A11
Beyer et al. (eds.), "Site Reliability Engineering", O'Reilly 2016, chapters on service level objectives and production readiness	A10 inspiration
Kleppmann, "Designing Data-Intensive Applications", O'Reilly	A4 and A5 inspiration only
Xu, "System Design Interview", volumes 1 and 2	Section 8 inspiration only
System Design Document Template (`system-design/system-design-document`)	The document under review
Architecture Review Board Request Template (`architecture/architecture-review-request`)	Board submission
Architecture Evaluation Report Template (ATAM) (`architecture/atam-evaluation`)	Deeper quality-attribute evaluation
Threat Model Template (`security/threat-model`)	A9 evidence
Zero Trust Architecture Plan Template (`security/zero-trust-architecture`)	A9 for trust boundaries

Standard and licence note

Based on common industry practice for design reviews and system design interviews, informed by the public SEI ATAM report and the AWS Well-Architected Framework cited in 9.2. Books listed in 9.2 are inspiration only; no text, diagrams or figures are copied from them. The weights, levels and decision bands are illustrative and should be calibrated by each organisation. This is original text; check the current versions of the cited frameworks. Template licence: MIT.

Related templates

System Design