How to Run Architectural Reviews with the Simonyan Framework
For Backend engineers and tech leads conducting architectural reviews · Based on Simonyan System Design Architecture Skill
// TL;DR
The Simonyan System Design Architecture Skill provides a structured checklist for evaluating existing architectures. Use it during architectural reviews to identify single points of failure, validate database and protocol choices against actual data patterns, audit API contracts for consistency and security, and verify that every past architectural decision has a documented trade-off. It transforms vague review sessions into systematic audits with actionable findings.
Why do most architectural reviews produce vague recommendations?
Most architectural reviews lack a systematic framework. Engineers discuss components in isolation—"the database seems slow" or "we should add caching"—without tracing the full request flow or understanding the original design decisions. The result is a list of opinions rather than a structured audit.
The Simonyan System Design Architecture Skill solves this by giving you a repeatable 10-step workflow that works both for designing new systems and for evaluating existing ones.
How do I apply the Simonyan framework to an existing system?
Retrace the 10-step workflow against the current architecture:
1. Map the baseline. Can you trace a single request from DNS resolution through to the response? Document every component it touches.
2. Verify tier separation. Are the web tier and data tier independently scalable? If they are on the same server, flag this immediately.
3. Audit database choices. Does the database match the data shape? A SQL database storing unstructured JSON blobs at massive scale is a red flag. A NoSQL store handling complex relational queries with JOINs is equally problematic.
4. Review the scaling strategy. Is the system relying on vertical scaling? Check for hard resource caps and single points of failure.
5. Examine load balancing. What algorithm is in use? Is it appropriate for the traffic pattern? Are health checks configured?
6. Hunt for single points of failure. Check every critical component: load balancer, primary database, cache layer, message broker. If any single component's failure takes down the system, document it.
7. Evaluate the API style and protocols. Is gRPC being used for browser-facing traffic? Are WebSockets used where HTTP polling would suffice (or vice versa)?
8. Audit the API contract. Check for verb-based URLs, missing pagination, inconsistent naming, missing versioning, and incorrect status codes.
9. Apply the four-principle checklist. Consistency, simplicity, security (authentication, authorization, rate limiting, input validation), performance (caching, pagination, payload size).
10. Document missing trade-offs. For every architectural decision, ask: "What was gained and what was given up?" If nobody can answer, the decision was likely made without proper evaluation.
What are the highest-impact findings in a typical review?
In practice, the most common issues the Simonyan methodology surfaces are:
- Undocumented single points of failure. The load balancer, primary database, or cache has no redundancy, no health checks, and no self-healing.
- Database mismatch. SQL being used for data that is naturally unstructured, or NoSQL being used where ACID transactions are critical (e.g., payment processing).
- Missing pagination. List endpoints returning entire datasets, causing performance degradation as data grows.
- No API versioning. Backend changes immediately break all existing clients with no migration path.
- Vertical scaling dependence. The team plans to "upgrade the server" when traffic grows, instead of designing for horizontal scale.
How do I present findings so they lead to action?
For each finding, use the Simonyan trade-off articulation format:
- Current state: Describe what is in place.
- Risk: What is given up by the current design.
- Recommendation: The alternative approach.
- Trade-off of the recommendation: What the new approach costs.
This structure prevents findings from sounding like complaints and instead frames them as defensible engineering decisions.
Start your next architectural review by walking the team through the Simonyan 10-step workflow. Assign each step to an engineer or squad, and reconvene with documented findings using the trade-off format. This transforms a meeting into a structured audit with clear ownership.
// FREQUENTLY ASKED QUESTIONS
How often should I run architectural reviews using this framework?
Run a full review quarterly or whenever the system undergoes a significant change (new service, 10x traffic growth, major feature launch). Use the Simonyan framework as a recurring checklist. Between full reviews, use steps 6 (single points of failure) and 9 (API design checklist) as lightweight monthly audits.
Can I use this framework to review a monolith?
Yes. The Simonyan methodology works for monoliths and microservices equally. For monoliths, focus on tier separation (step 2), database choice (step 3), and single points of failure (step 6). The framework will often surface that the monolith itself is a single point of failure and help you plan the scaling strategy—whether that means horizontal scaling of the monolith or decomposing into services.
How do I handle pushback when the review surfaces issues with existing decisions?
Use the trade-off format: state what the current design gains and what it gives up. This depersonalises the finding. The Simonyan methodology explicitly teaches that there is no perfect answer—only decisions with trade-offs. Framing findings this way makes them easier for teams to accept and act on.