| name | system-design-verifier |
| description | Audit architectures against failure modes (resilience, scalability, consistency, security). Use when reviewing a new system design or architecture proposal, before major infrastructure changes, or during post-incident analysis of architectural weaknesses. |
| license | MIT |
System Design Verifier
Audit proposed or existing architectures against common failure modes.
When to Use
Whole-system / proposal-level audit against failure modes (resilience,
scalability, consistency, security). Narrower siblings: intra-service layering
and dependency direction → clean-architecture-guide; the specific failure
modes of crossing a network boundary → distributed-systems-checklist. Use
this for the system silhouette, those for the pieces inside it.
Procedure
- Identify Interfaces: Map all network boundaries (REST, gRPC, queues, DB connections).
- Verify Resilience: For each boundary — what happens if this dependency is down or slow? Ensure timeouts, retries, and circuit breakers are designed.
- Verify Scalability: Identify stateful components. Can they scale horizontally? Are there single points of failure?
- Verify Consistency: Is data eventually consistent or strongly consistent? Does the business logic handle eventual consistency correctly (e.g., Sagas for distributed transactions)?
- Verify Security: Are interfaces authenticated? Are trust boundaries documented? Is data encrypted in transit and at rest?
- Report: Produce a structured findings list: component, risk, severity, recommendation.
Completion
- All interfaces mapped and verified across 4 dimensions (resilience, scalability, consistency, security)
- Findings report produced with severity and recommendations
Anti-Patterns
- Reviewing only the happy path — failure modes are the whole point
- Ignoring data consistency model — leads to subtle bugs under load
- No severity ranking — treating all findings equally dilutes focus
