System Design Review
Priority: P1 (HIGH)
Score claims against evidence appropriate to the declared review scope. A proposed design may support a design-readiness verdict through stated mechanisms and planned validation; it cannot claim operational readiness from plans alone. An implementation review requires implementation evidence; an operations claim requires production runtime/deployment evidence.
Nine Axes (score each applicable axis 0-10)
| Axis | Scores 10 when | Scores 0 when |
|---|---|---|
| Requirements | Functional, NFR, and out-of-scope written with owners | Only a feature description exists |
| Capacity evidence | Peak QPS, storage, and bandwidth computed and current | Numbers absent or older than the last traffic change |
| Redundancy | Failure domains, recovery mechanisms and ownership fit the stated objective; proposals include validation criteria, operations claims require measured drills | Critical SPOF or no viable recovery for the stated objective |
| Data scaling | Access patterns mapped, ownership single, growth path stated | One shared store, no growth plan, unbounded tables |
| Caching | Hot read paths cached with TTL and invalidation defined | No cache on a proven hot path, or uninvalidatable cache |
| Async offload | Slow/bursty work is isolated when required by stated SLO or failure constraints, with bounded drain/recovery; bounded synchronous work is valid when it meets them | Required isolation is absent or synchronous coupling violates the stated constraints |
| Observability | Signals, alert ownership, runbooks and validation fit the declared scope; operations claims require observed telemetry | No relevant signals, owner or response path for a material risk |
| Rollout | Canary or flag with metric rollback trigger and reversible migrations | Big-bang deploy, irreversible migration |
| Cost proportionality | Spend is sized to the traffic and the risk, and someone can state it | Topology bought for an imagined scale nobody measured |
Report each applicable axis with evidence and a declared profile weighting. Use an applicable-axis denominator
(10 × applicable-axis count), not a fixed /90, when an axis is justified N/A.
Profile-Aware Scoring
- Declare the system profile and weighting before scoring. An axis may be
N/Aonly when the profile and evidence show that it is outside the system's risk envelope; record the rationale, exclude it from the denominator, and do not silently convert it to zero. - Do not reward adding a cache, queue, replica, or region by vocabulary alone. A component earns credit only when a measured constraint, invariant, owner, cost, and failure/recovery behavior require it; unjustified machinery lowers cost proportionality and operability.
- Review HLD and LLD as one trace: requirements and shaping decisions must resolve into component ownership, contracts, verification, and a stated changed-constraint trigger. A diagram is optional when prose answers the question.
- Separate lifecycle (
proposed|implemented|retired), source kind (code|document|runtime|deployment), and evidence confidence (unverified|assumed|documented|observed). Code/document citations aredocumented, not deployment proof; runtime/deployment captures may beobserved.assumedandunverifiedcarry no citation; explicit citations requireevidence_kind.
Scope-Qualified Semantic Review
Lexical checks are smoke signals, not proof of a sound design. Apply the independent behavioral rubric in semantic evaluation. Record missing calculations, mechanisms, adverse timelines, invariants, recovery, and scope-specific evidence as findings even when expected vocabulary appears.
Review Method
- Establish ground truth first: current traffic, data volume, incident history, and the top pain the owner reports.
- Score the nine axes against artifacts and metrics; mark any unverifiable claim
UNVERIFIED. - Trace the hottest and the most critical path end to end; the worst hop is the real bottleneck.
- List findings as
severity - axis - evidence - consequence - smallest fix. - Convert findings into a roadmap: stop-the-bleeding now, structural next, optional later.
- Check operability: who runs this at 3am, which team owns which piece, and whether that team can actually operate it.
Common Mistakes to Check
- Architecture drawn before requirements or numbers existed.
- Redundancy claimed but sharing one config plane, credential, or control plane.
- Cache added over a query that was never optimized.
- Sharding adopted before indexing, replicas, and caching were exhausted.
- Queue with no drain-rate budget, no DLQ, and alerting on depth rather than age.
- Alerts on CPU rather than user-visible symptoms or error-budget burn.
- Migration and code shipped as one irreversible step.
Anti-Patterns
- No score without evidence: cite the metric, artifact, or drill; otherwise mark
UNVERIFIED. - No rewrite recommendation by default: prefer the smallest fix that removes the proven bottleneck.
- No uniform severity: rank by user impact and reversibility, not by axis order.
- No finding without a next action: every gap gets an owner-ready fix.
References
- Scorecard - scoring rubric, weighting guidance, report template
- Mistakes Table - failure symptom, root cause, and corrective action
