Architecture

Architecture Reviews

An architecture review is not an audit — it is a structured way to surface risk, validate assumptions, and improve decisions before they become expensive. The goal is better architecture, not a sign-off.

Mangesh MandlikLast updated: 1 November 2026

What Is an Architecture Review?

Architecture review, risk discovery, and decision quality

An architecture review is a structured examination of a system or proposed design to surface risks, validate assumptions, and identify failure modes before they materialise in production. The goal is not to declare the design universally correct. It is to make the highest-risk assumptions visible and ask what happens if each one is wrong.

A well-run review produces a prioritised risk register, not a vague score. Each finding should connect the risk to evidence, blast radius, and a realistic follow-up action.

Risk register

Ordered list of findings with assumptions, evidence, recommendations or options, owner, priority, and follow-up.

Blast radius

How much of the system or business is affected if an assumption fails. Larger blast radius usually deserves earlier attention.

Visual Story

System → review finds bottlenecks → recommendations applied

Architecture Reviews

Pre-Review

0 / 0

🔎Up nextReview Starts

⤢ Expand for synchronized narration timeline

The review finds two unprotected ceilings in Scene 2 and an unconstrained blast radius in Scene 3. Both are addressed before peak season rather than discovered during it.

Problem It Solves

Why architecture reviews matter before production

Architecture reviews exist because significant decisions are made under uncertainty: incomplete information, time pressure, changing requirements, and assumptions about load, failure, security, cost, or team capability that may not hold in production.

Discovering a risk in review usually costs analysis, discussion, and planned engineering work. Discovering the same risk during a production incident or peak event usually costs customer impact, emergency mitigation, and reduced decision quality. Reviews move that discovery earlier, while change is still cheaper and calmer.

Types of Architecture Review

Different review types answer different questions

1. Design review

Reviews a proposed design before or during implementation. Focus: requirements, assumptions, trade-offs, and whether the chosen option fits the problem.

2. Production-readiness review

Checks whether a specific service or change is ready to go live. Focus: operability, rollback, observability, dependencies, failure handling, and ownership.

3. Capacity or scale review

Examines whether the system will handle expected growth or a known event. Focus: ceilings, saturation points, queueing behaviour, and dependency limits.

4. Security-focused review

Deep-dives trust boundaries, identities, privileges, secrets, abuse scenarios, and compensating controls for the relevant threat model.

5. Existing-system health review

Assesses a live system retrospectively. Focus: accumulated risk, recurring incidents, architectural drift, and where the design no longer matches reality.

Review Checklist

Expand a dimension to see the key questions

Architecture review checklist: what should you actually review?

Start with the system's real requirements and constraints, then review the architecture dimension by dimension: expected load and saturation points, failure modes and blast radius, trust boundaries and privileges, operability and incident response, cost shape, and maintainability over time. The checklist below is a prompt for structured questions, not a substitute for judgment.

How Architects Think

A review is only as good as the questions it asks

A weak review checks whether the system matches the slide deck. A strong review probes whether the assumptions behind that design are supported by evidence and whether the failure modes are acceptable if those assumptions fail.

Risk prioritisation can consider blast radius, likelihood supported by evidence, detectability, recoverability, requirement or SLO impact, and remediation cost. Those inputs are often partly qualitative, so avoid pretending a neat numeric formula makes the judgment precise. The output should still be concrete: assumptions, risks, evidence, unresolved questions, options or recommendations, owner, priority, and how follow-up will be checked.

What would change your decision? If the review surfaces a risk the team already knew about but never prioritised, the next question is often about ownership or incentives, not awareness. And if that risk later materialises, it should feed directly into Incident & Postmortem Analysis.

Illustrative Scenario

Reviewing an e-commerce checkout service before peak season (illustrative scenario; all figures are invented)

Context: a checkout service is reviewed 6 weeks before Black Friday. Last year's peak was 800 orders/minute; this year's forecast is 1,400.

Scalability finding: the payment integration uses a single synchronously-called HTTP endpoint with no timeout. Under load, slow payment responses may exhaust the connection pool and stall the checkout flow (the failure mechanics are walked through in Reliability & Resilience).

Reliability finding: the primary database has a read replica but failover has never been tested. Replica lag reaches 12 seconds under high write load. A failover during peak could promote a materially stale replica.

Operability finding: the on-call runbook covers 3 failure scenarios. There are 14 distinct alert types in the monitoring system. On-call engineers are likely to encounter cases that do not yet have clear guidance during peak.

Outcome: 3 high-risk and 5 medium-risk items, each with explicit assumptions, evidence, recommended options, owner, and expected follow-up date. Two high-risk items are resolved within 4 weeks; the remaining one has a documented mitigation plan and re-review date.

Trade-offs

How a review is framed determines what it finds

Risk-finding vs sign-off

An architecture review positioned as an approval gate creates incentives to hide uncertainty. Positioned as structured risk-finding, it produces more honest input and better outcomes.

Reviewer familiarity vs outside perspective

A reviewer who built the system has context but may also have blind spots. An outside reviewer sees fresh patterns but may misread implicit constraints. Strong reviews benefit from both perspectives.

Written review vs structured conversation

A written review document is durable but one-directional. A structured conversation surfaces reasoning and assumptions that documents often leave implicit. The best reviews combine both.

What Can Go Wrong

Why reviews fail to find what matters

🔒Approval gate framing

Review positioned as sign-off. Team hides uncertainty and presents only strengths. Real risks stay hidden.

⚖️Wrong calibration

Review spends equal time on every dimension regardless of the system’s actual risks. A payment system may need far more time on reliability and security than on minor cost tuning.

😊Normal operation only

Review evaluates the happy path but not partial outages, slow dependencies, backlog growth, or failure recovery.

💥No blast radius analysis

Findings are listed but not ordered by impact, recoverability, or evidence. The team cannot tell what should move first.

📋Findings without actions

Review identifies risks but leaves no owner, options, or follow-up checkpoint. The document exists, but the architecture does not improve.

📅No follow-up

Review findings are never revisited. Months later the same risks reappear during an incident or another review.

When To Use / When Not To Use

When architecture reviews add the most value

✓ Conduct a review when

→ Before a known traffic event, launch, or compliance milestone
→ When a system crosses a new scale, complexity, or dependency threshold
→ Before committing to a costly or hard-to-reverse architectural decision
→ When a new team inherits an existing system with unclear assumptions

⚠️ Invest proportionally — not for

→ Low-blast-radius internal tools where the review overhead exceeds the likely risk reduction
→ Short-lived systems that will be retired before meaningful complexity accumulates
→ Situations where all findings will be deferred with no owner or follow-up
→ Compliance theater that wants a checkmark rather than genuine risk discovery

Architect's Challenge

You are reviewing a checkout service 6 weeks before Black Friday. The system handles 800 orders/minute today; peak forecast is 1,400. What is the single most important question to answer in the review?

Remember· 30-second mental model

An architecture review surfaces the risks you have not yet paid the cost for. The output is a prioritised risk register, not a score.

1Match the review type to the question: design, production-readiness, capacity, security, or existing-system health.
2Probe failure modes and assumptions, not just normal operation and happy-path diagrams.
3Prioritise findings with judgment: blast radius, evidence-backed likelihood, detectability, recoverability, and requirement impact all matter.
4A strong review output includes assumptions, risks, evidence, unresolved questions, options or recommendations, owner, priority, and follow-up.
5Follow-up matters as much as discovery. A known risk with no owner is simply deferred failure.

Key lesson

‘If the payment provider slows down, checkout exhausts its connection pool in about 90 seconds’ is a useful review finding. ‘7/10 reliability’ is not.