pa-10 step 02 — The design-review checklist
A design review pressure-tests a proposal before code is written, so the expensive mistakes (a boundary in the wrong place, a missing failure mode, no rollback path) surface when they're cheap to fix. The reviewer's job is to find the thing the author didn't think of — kindly. This checklist doubles as a structure for the systems-design interview round (see [gw-00 / pa-00 INTERVIEW.md]).
The checklist
Problem & scope
- What are we optimizing — which "-ilities" (latency, throughput, consistency, cost, dev velocity)? Stated and prioritized?
- Scale: RPS, data size, event rate, # teams/consumers, growth?
- What's explicitly out of scope / a non-goal?
Boundaries & contracts (pa-01, pa-02)
- Services split by bounded context, not technical layer or table?
- Any dependency cycles / shared databases / distributed-monolith smells? (Run the fitness function, pa-01/pa-10.)
- Contracts explicit and versioned? Compatibility plan? (pa-02)
- Sync vs async chosen per edge, with the cost owned? (pa-03)
Data & consistency (pa-04, pa-05, pa-06)
- Partitioning strategy + key (skew/hotspots)? Resharding cost?
- Consistency model per dataset (the weakest that's correct)? CAP/PACELC?
- Dual-write avoided (outbox)? Cross-service workflow = saga, not 2PC?
- Delivery semantics (at-least-once + idempotent consumers)? Ordering?
Failure & reliability (pa-09, gw-06)
- Failure modes enumerated? Blast radius (pa-01) understood?
- Timeouts, retries (+budget+jitter), circuit breakers, bulkheads, backpressure, load shedding?
- SLOs + error budget defined? What degrades first (graceful degradation)?
- Metastable-failure / retry-storm risk considered?
Delivery & operability (pa-07, pa-08, gw-11, gw-12)
- IaC + GitOps? Progressive delivery + automatic rollback?
- Observability: RED/USE metrics, tracing across async hops, the alerting (symptom-based, not cause-based)?
- Migration plan (strangler-fig / shadow → canary → ramp)? Rollback tested?
Evolution & people
- What changes are likely, and does the design absorb them (evolutionary architecture)?
- Which invariants become fitness functions in CI?
- Is there an ADR for the key decisions and rejected alternatives?
- Security/authz (gw-07), data privacy, multi-tenancy?
How to run it well
- Send the doc + this checklist ahead; review the document, not the person.
- Drive toward a decision (and an ADR), not an open-ended discussion.
- The reviewer adds value by finding the missed failure mode and by teaching — design review is mentorship at the architecture level.
- Disagree-and-commit: record dissent, decide, move; revisit if data changes.
Tasks
- Run this checklist against a recent design at work; count how many boxes were implicitly assumed vs explicitly answered.
- Use it as the spine for a mock systems-design interview (pa-00 INTERVIEW.md) and notice it covers every round.