System Design Review
A design can look complete because it contains a diagram and a technology list. The harder question is whether its decisions can be traced back to user needs and tested under failure, growth, and change.
A useful review follows that path instead of treating architecture as an isolated phase.
Start with the Work
Write down the important user stories and rank them. Separate functional requirements—what users can do—from quality requirements such as latency, availability, security, and cost.
Make quality requirements measurable when possible. “Fast” is difficult to test; a latency target at an expected load is inspectable.
Review the Main Decisions
| Area | Questions to make explicit |
|---|---|
| Architecture | What are the major components, and why are their boundaries useful? |
| Domains | Which business capabilities belong together? Where do dependencies cross domain boundaries? |
| Data | What are the models, schemas, retention rules, and required queries? |
| Scale | Can capacity grow vertically, horizontally, or both? Where is load balanced? |
| Reliability | Which failures are expected, how are they detected, and how does recovery work? |
| Availability | What is replicated, what downtime is acceptable, and what disaster must the recovery plan survive? |
| Performance | What latency and throughput targets matter? Where can batching, encoding, or caching help? |
| Security | How are identities authenticated, permissions granted, data encrypted, and secrets stored? |
| Testing | Which unit, integration, system, acceptance, performance, and security checks provide evidence? |
| Operations | What must be monitored, alerted on, documented, and maintained? |
| Cost | What are the infrastructure, licensing, subscription, and growth costs? |
| Migration | Can the new design interoperate with existing systems, and how will data move safely? |
Storage decisions should follow the workload rather than a product name; see choosing cloud data storage. If useful work crosses process or machine boundaries, also review the failure and latency costs described in distributed systems.
Traceability Is the Deliverable
The review is successful when someone can follow each major decision back to a requirement and forward to a verification method.
user need → design decision → operational risk → test or measurement
A decision without a requirement may be unnecessary complexity. A requirement without a design response is a gap. A design promise without a test, metric, or recovery exercise is still an assumption.