Every engineer who has spent significant time in architecture discussions has seen the same dynamic: a proposed solution is presented, its proponents defend it, critics pick at details, and the group gravitates toward whichever solution has the most enthusiastic advocate rather than the best trade-off profile.
This is not evaluation. It’s preference arbitration.
Effective architecture review requires a framework that separates the emotional investment from the analysis — that forces explicit engagement with dimensions like cost, risk, and reversibility that advocates tend to minimize and critics tend to ignore.
The Trap of Solution Love
Engineers fall in love with solutions. This is not entirely a flaw — passion for a solution often comes from genuine insight into its properties. But it produces systematic biases in how proposals are evaluated:
- Advantages are presented fully; disadvantages are minimized or deferred (“we can fix that later”)
- Complexity is described as “we’ve done this before” when the team has done similar things
- Risk is described in terms of “what could go wrong” but not “what is the probability and impact”
- Alternatives are considered briefly and dismissed without rigorous comparison
The job of an architecture review is not to validate the proposal. It’s to stress-test it — to find the conditions under which it fails, the assumptions that might be wrong, and the alternatives that might be better.
The Evaluation Framework
A useful architecture review asks seven questions, in roughly this order:
1. What problem does this solve?
Before evaluating any solution, be explicit about the problem. Write it down. Include:
- What is currently happening?
- What is the desired state?
- What are the constraints (time, cost, team skills, existing systems)?
- How will we know if the solution worked?
If the problem statement is vague, no evaluation of solutions is valid. “We want better scalability” is not a problem statement. “The orders service handles 500 requests/second at p99 500ms, and we need to support 2,000 requests/second at p99 300ms within 6 months” is.
2. What is the total complexity cost?
Complexity has two forms:
Essential complexity: inherent in the problem. A distributed system that needs eventual consistency has essential complexity that can’t be avoided.
Accidental complexity: introduced by the solution. A system that uses Kafka, Redis, 5 microservices, and a saga orchestrator when a well-structured monolith would have sufficed has high accidental complexity.
Questions that surface accidental complexity:
- What does a new engineer need to know to work in this system?
- How many separate components must be understood to debug a production incident?
- How many moving parts does a standard deployment involve?
- How many failure modes does this introduce?
Complexity is the primary long-term cost of a technical decision. Solutions that appear fast to implement often have high ongoing complexity costs.
3. What are the specific risks?
Every architectural decision has risks. The useful question is not “could something go wrong?” (yes, always) but “what specifically could go wrong, with what probability and impact?”
A risk register for an architectural proposal:
| Risk | Probability | Impact | Mitigation |
|---|---|---|---|
| Kafka partition rebalancing causes consumer lag spikes | Medium | High | Monitor lag, auto-scaling consumers |
| Team unfamiliar with event sourcing delays delivery | High | Medium | Include training time in estimate |
| PostgreSQL schema migrations block traffic at scale | Low | High | Test on production data volume before launch |
Unidentified risks don’t disappear — they become incidents. Explicit risk identification forces consideration of mitigation strategies during design rather than during incidents.
4. Does it scale to the required load?
“Scalable” means nothing without specific numbers. Evaluate against actual requirements:
- What is the expected load at launch?
- What is the load at 1 year, 3 years?
- What is the failure mode when load exceeds expected levels? (Graceful degradation? Hard failure? Cascading failure?)
Beware of “it will scale” without analysis. The classic failure: a system designed for 1,000 concurrent users that needs careful re-architecture at 10,000 — not because 10,000 is unreasonable load, but because the architecture assumed a load level that the business would exceed in 18 months.
Questions:
- Where are the bottlenecks? (Database writes? Memory? CPU? Network?)
- How do you scale those bottlenecks?
- What does scaling cost (operationally and financially)?
5. What are the reliability properties?
Reliability is about system behavior under failure conditions. Questions:
- What components can fail?
- What happens to the system when each component fails?
- What is the blast radius of each failure mode?
- How quickly can the system recover?
- What is the expected availability?
A useful exercise: “Chaos Monday.” For each component in the proposed architecture, describe what happens if it becomes unavailable for 5 minutes, 1 hour, or 1 day. If the answer for any component is “the entire system is down,” that component is a single point of failure that deserves explicit design attention.
6. What are the security implications?
Architecture decisions create security properties — intended and unintended.
- What are the trust boundaries?
- What data flows across each boundary?
- What is the attack surface (network-accessible components, data stores, external integrations)?
- What is the blast radius of a compromise at each component?
Security should be evaluated during architecture review, not after. Adding security to a poorly-designed architecture is expensive. Designing security in from the start is cheaper and more effective.
7. How reversible is this decision?
Some architectural decisions are easily reversed. Others are not.
- Can this be undone in a week? A month? A year? Never?
- What is the cost of reversing this decision if it turns out to be wrong?
- How confident are we in the assumptions that make this the right choice?
Irreversible decisions require higher confidence before committing. Reversible decisions can be made with less information.
When a decision is largely irreversible (database engine, event streaming platform, inter-service communication protocol), invest more time in the evaluation. When it’s largely reversible (library choice, specific algorithm), make a reasonable decision quickly and move on.
Evaluating Alternatives
A proposal presented without alternatives is not ready for review. The choice of architecture A is only meaningful in comparison to alternatives B and C.
For each serious alternative, apply the same seven questions. Then compare:
| Dimension | Option A | Option B |
|---|---|---|
| Complexity | High | Medium |
| Risk | Low (team familiar) | Medium (new technology) |
| Scalability | To 10K req/s | To 100K req/s |
| Delivery time | 4 weeks | 8 weeks |
| Reversibility | Low | Medium |
No option wins on every dimension. The choice is about which trade-offs fit the current context.
The Reviewer’s Posture
Effective architecture reviewers:
Ask clarifying questions before challenging: “Help me understand how this handles [scenario]” before “this doesn’t handle [scenario].”
Separate understanding from evaluation: fully understand the proposal before evaluating it. Challenging from incomplete understanding wastes time.
Distinguish “I would do it differently” from “this is wrong”: architectural preferences are real but shouldn’t dominate the evaluation. Focus on functional properties (does it work? at what cost?) not stylistic ones.
Make trade-offs explicit: “This is simpler to build but harder to scale” is more useful than “this is bad.”
Document the reasoning: write down the options considered, the decision made, and the reasoning. This is the Architecture Decision Record. It provides value for months and years after the decision.
When to Proceed and When to Stop
Sometimes architecture review reveals that a proposal is not ready: the problem is not clearly defined, the risks are not understood, the scaling requirements are not established. In those cases, the review should produce a list of questions that must be answered before evaluation can continue — not a rushed decision on insufficient information.
The cost of a bad architectural decision is paid continuously, in engineering time and operational complexity, for years. The cost of a one-week delay to properly evaluate a decision is a week.
Review decisions with the gravity they deserve, proportional to how reversible they are.