Design Review Process

Scale review to blast radius

A design review is a decision and risk-discovery process, not a ceremony every change must pass. Review effort should scale with blast radius, reversibility, uncertainty, security exposure, and the number of teams affected. A local refactor with strong automated tests may need peer review only. A change to data ownership, an authentication boundary, a public API, or a regional recovery strategy deserves broader scrutiny because mistakes are expensive to reverse and affect more users.

Define review triggers so teams can choose the right path without relying on status or personal influence. Triggers can include a new persistent data store, a cross-service dependency, a material SLO change, an external integration, a security-sensitive flow, or a migration with irreversible steps. Keep the bar explicit and allow a lightweight path for work below it. The goal is to spend review attention where it reduces meaningful risk, not to maximize meeting count.

Prepare a decision-ready proposal

Circulate pre-reading early enough for reviewers to understand the context and ask questions. A useful proposal states the problem, affected users and systems, constraints, options, recommendation, risks, operational plan, and the specific questions that need review. Include diagrams or estimates only where they support a decision. Mark assumptions and evidence quality so reviewers know which claims can be trusted and which need validation.

Name the decision owner and the people whose expertise is needed. A security reviewer, data owner, operator, and product stakeholder may each see a different risk. Do not invite a large group without a purpose; too many attendees can dilute ownership and make it harder to reach a conclusion. Ask reviewers to comment on identified questions and important failure modes before the meeting.

Conduct a focused review

Start by confirming the decision and constraints. Separate disagreement about facts from disagreement about priorities. A performance assumption can be measured; risk tolerance belongs to the accountable owner. Walk through the relevant flow, trust boundaries, data lifecycle, failure modes, rollout and rollback, and operational responsibility. Keep discussion anchored to the proposal instead of redesigning unrelated parts of the system.

A review should produce one of several clear outcomes: accept, accept with tracked conditions, request specific evidence, or defer for a material gap. Record who decides and what changes are required. A list of comments without a conclusion leaves the implementation team guessing. If the design changes materially after review, determine whether the change crosses a trigger that requires another review.

Close actions and preserve rationale

Track review actions with an owner, due point, and closure evidence. Distinguish blocking conditions from follow-up improvements. Link the decision to an ADR or design record where future teams can find it, and update that record if the accepted design changes. A meeting note is not a durable architecture decision unless it captures the context and outcome.

Review is not a substitute for tests, threat modeling, operational readiness, or code review. It can identify questions that those activities must answer, but it cannot prove the implemented system matches the proposal. Make review evidence part of the delivery path: link tests, load results, security findings, dashboards, and rollout checks to the relevant actions. This keeps architecture intent connected to what ships.

Review a payment-provider change

Assume a team proposes moving payment authorization from a synchronous provider call to an adapter that supports two providers and failover. The change affects money movement, duplicate authorization risk, credentials, reconciliation, and support workflows. It clearly meets a high-impact review threshold. Identify a decision owner from the payments domain and reviewers for security, finance reconciliation, operations, and the affected API team.

The pre-read should show the current and proposed request flows, idempotency strategy, provider-selection rule, timeout and retry behavior, credential handling, reconciliation process, rollout plan, rollback condition, and open questions. State the expected reliability and cost benefits, but also identify the assumptions about provider consistency and duplicate behavior. Ask reviewers to focus on whether an authorization can be repeated, how uncertain outcomes are reconciled, and how operators detect a stuck payment.

Run the meeting to an outcome

Open by confirming the decision: whether the proposed failover behavior is safe to implement for the specified payment types. Walk through the timeout path. If the first provider times out after processing the request, the client cannot assume no authorization occurred. A retry needs an idempotency key and a reconciliation path. This is a concrete failure mode that is more useful than debating the abstract benefit of multi-provider availability.

If the review reveals the provider does not support the assumed idempotency behavior, record a blocking evidence action and defer approval for that flow. If the missing capability affects only a low-risk payment method, the decision owner may approve a constrained rollout with an explicit limit and monitoring. Distinguish a design condition from a suggestion so the team knows what must be complete before release.

Track implementation evidence

Assign each action to an owner: validate provider semantics, test duplicate requests, verify credential rotation, build a reconciliation dashboard, and rehearse rollback. Define closure evidence, such as a provider contract, automated test report, dashboard link, or recovery exercise result. Review the updated proposal if the chosen retry strategy or provider contract changes materially.

After implementation, compare the shipped behavior to the decision. Confirm that the idempotency key is persisted across retries, the alert detects ambiguous outcomes, and the runbook describes reconciliation. Close actions only when the evidence exists, not when a meeting note says they were discussed. Link the accepted outcome to an ADR and to the operational runbook so both future designers and on-call responders can find the rationale.

Exercise proportionality

Now compare a low-risk change such as renaming an internal module with no public contract or runtime effect. A heavyweight committee review would add delay without a matching reduction in risk. Normal code review and tests are likely sufficient. The contrast helps calibrate thresholds: review process should be predictable, but the depth of review depends on impact and reversibility.

Ask reviewers to independently read the proposal before the meeting. Collect comments and group them by decision, evidence, and follow-up. This makes the live discussion shorter and gives quieter reviewers a way to contribute. End by repeating the outcome, blocking conditions, owner, and next checkpoint. If no decision can be made, state exactly what information is missing and who will obtain it.

Avoid both bottlenecks and rubber stamps

Too little review can miss a cross-team dependency, unsafe migration, or operational gap before it becomes expensive. Too much review turns the architecture group into a queue and encourages teams to treat approval as paperwork. Set clear thresholds, provide a lightweight path, and make decision ownership explicit. Measure whether reviews reduce rework or incidents rather than celebrating the number of sessions held.

Pre-reading improves the meeting only if the document asks a real question and reviewers have time to respond. A deck sent minutes before the call is not meaningful pre-reading. Keep the proposal concise and link to detailed evidence. Use the meeting for unresolved trade-offs and decisions, not for silently reading material together.

Make actions verifiable

Action items should distinguish mandatory conditions from optional improvements. Each needs an owner and evidence of closure. A vague task such as "consider security" is not actionable; a defined threat review, test, or design update is. Track actions in the team's existing work system and link them to the decision so they do not disappear when meeting notes are archived.

An approval is not proof of correctness. The implementation may differ, assumptions may change, or a new dependency may increase risk. Connect review findings to tests, release checks, monitoring, and runbooks. Re-review only when a material trigger is crossed, not whenever a routine implementation detail changes. This preserves attention for changes that can alter the decision.

Design a fair review environment

Reviewers should challenge assumptions and failure modes without turning the session into a test of the presenter. Share context in advance, make room for operators and maintainers, and separate the quality of an idea from the seniority of its author. Record dissent and unresolved risk where it matters. A culture that punishes raising a concern will produce quiet meetings, not safer systems.

In an interview, explain how thresholds scale with blast radius and reversibility. Describe a decision-ready pre-read, a focused meeting, explicit outcomes, and owner-tracked actions. Give an example where a failure mode changed the decision and identify the evidence that closed the concern. Finish by distinguishing design review from code review and testing: each checks a different layer, and none substitutes for the others.

Reviewers should also make uncertainty and dissent safe to raise. Share the proposal early, invite written questions from people who may not speak first in a meeting, and distinguish a concern from a veto. The decision owner should explain how each material concern was resolved or accepted. This reduces the chance that hierarchy suppresses operational or security evidence. Keep a record of the accepted risk and its owner so a later incident can be compared with the assumptions made during review. If a review repeatedly discovers the same class of issue, improve the design checklist or delivery control rather than relying on individual memory. A lightweight review can be effective when its question, owner, evidence, and outcome are explicit.

Publish the outcome where implementers can find it before work begins.