Most production incidents trace back to a question nobody asked during design. An architecture review is a structured way to ask those questions while changes are still cheap. It does not need to be a heavy ceremony: a focused session of an hour or two, with the right people and a shared checklist, catches a surprising amount.

What an Architecture Review Is (and Is Not)

A review is a conversation about risk, not an exam the design team must pass. The goal is to surface assumptions, confirm that failure modes are understood and agree on follow-up work. It is not a place to relitigate every technology choice or to impose personal preferences.

Good reviews have three ingredients: a short written design document, a reviewer who did not build the system, and a record of decisions and open actions afterward.

Preparing the Review

Ask the owning team to bring a one-page summary covering:

• What the system does and who depends on it.
• A simple diagram of components, data flows and trust boundaries.
• The expected load shape, in plain terms, such as steady, spiky or seasonal.
• The recovery targets the business has agreed to.

If the team cannot state the recovery targets, that is the first finding. Everything else depends on them.

The Five Areas to Walk Through

Many providers publish architecture frameworks organized around similar pillars. The names differ, so consult the vendor’s current guidance, but the areas below cover the durable ground.

Security and Identity

Check how identities are managed, whether permissions follow least privilege, where secrets live and how data is encrypted in transit and at rest. Confirm that administrative access is logged and that no long-lived credentials are embedded in code or images. Compliance obligations differ by jurisdiction and industry, so involve qualified security or compliance professionals where regulated data is in scope.

Reliability

Look for single points of failure, health checks, timeouts, retries with backoff and sensible limits on how failures cascade. Ask what happens when each dependency is slow rather than down, since slowness is often more damaging than outright failure.

Operations

Ask how the system is deployed, observed and rolled back. Can an on-call engineer who did not build it understand a dashboard and follow a runbook at three in the morning? Is infrastructure defined as code so environments can be reproduced?

Performance

Confirm that the team has load-tested at least roughly and knows the first bottleneck. Check that scaling mechanisms are tested, not merely configured.

Cost

Ask for a rough cost model: the main cost drivers, who owns the budget and what triggers an alert. Resources should be tagged so spending can be attributed.

The Checklist

Area	Question to Ask	Evidence to Request
Security	Are permissions scoped to least privilege?	Role definitions and access review notes
Security	Where are secrets stored and rotated?	Secrets manager configuration
Reliability	What is the recovery time and data loss target?	Written, agreed objectives
Reliability	Has a restore from backup been tested?	Dated restore test record
Operations	Can a deployment be rolled back quickly?	Documented, rehearsed rollback
Operations	Do alerts map to runbooks?	Linked runbook for each page-worthy alert
Performance	What fails first under load?	Load test summary
Cost	Who owns the budget and alerts?	Named owner and tagging policy

Turning Findings Into Decisions

Not every gap must be fixed before launch. Sort findings into three groups: must fix before launch, accept with a documented owner and revisit date, and backlog. The important discipline is writing down accepted risks with a name next to them. Unowned risks quietly become permanent.

A Realistic Example

Consider a team about to launch a customer-facing reporting service. During the review, a reviewer asks what happens if the primary database is unavailable for thirty minutes. The team realizes the service retries aggressively with no backoff, which would likely overwhelm the database during recovery. They also discover that backups exist but nobody has ever restored one. Neither issue required a redesign: the team adds exponential backoff, schedules a restore test and records one accepted risk, a single-region deployment, with a quarterly review date. Launch slips by a few days, and two likely incident causes are removed.

Keeping Reviews Lightweight

Reviews fail when they become bureaucratic. A few habits help:

• Use the same checklist each time so teams know what to expect.
• Review early for significant designs and again before launch for changes in risk.
• Keep notes short and store them next to the code or design document.
• Rotate reviewers so knowledge spreads and blind spots shrink.

Frequently Asked Questions

Who should attend an architecture review? The design owners, one or two engineers from outside the team, and someone who represents operations and security concerns. Keep the group small enough that everyone speaks.

How long should a review take? One to two hours for most services. If it regularly runs longer, the design document is probably too vague or the scope too broad.

Do small projects need a review? A lighter version is still useful. Even a fifteen-minute check against the checklist can expose missing backups or over-broad permissions.

What if the team disagrees with a finding? Record the disagreement, the reasoning and the owner of the decision. The aim is a conscious choice rather than unanimous agreement.

Should reviews be repeated after launch? Yes, when load, data sensitivity or dependencies change significantly, and on a regular cadence for critical systems.

Next Step

Copy the table above into your team’s wiki, adapt the questions to your environment and schedule a review for the next service heading to production. Even one honest session will show you which questions your team has been skipping.