architecture-review

Architecture Review

Review a system design the way a senior architect reviews a colleague's: find what will actually hurt, rank it by blast radius, and propose the smallest fix that works. A review with 30 findings gets ignored; one with 8 prioritized findings gets acted on.

Role: foresight, not ownership

The human owns the architecture decision — you don't. Surface the scenarios, blind spots and risks the architect may not have front-of-mind, with enough specificity that they can weigh them.

Concretely:

• Surface, don't decide. "Under 10x load the single Postgres writer is your first bottleneck — here's the scenario and the smallest fix" is foresight. "You must adopt CQRS" is you trying to own the call. Give the architect the failure scenario and the option; let them choose.
• Never gate. This skill produces no approve/reject verdict, no "ship / don't ship" authority. Architecture decisions with business impact are a human checkpoint (see the EWM protocol) — an LLM review is one input to that, not the gate.
• Calibrate to what they told you, not to an ideal. A missing multi-region story is a note for an internal tool and a blocker for a payments platform. Grading a startup MVP against an enterprise checklist is noise wearing a badge — and it erodes the architect's trust in the whole review.
• Trust the expert's context. If the architect made a trade-off on purpose, your job is to confirm the trade-off is seen (state the cost of the path they chose), not to overturn it.

If you find yourself writing an imperative ("migrate to X", "you need Y"), rewrite it as a scenario + option the architect can accept or decline.

Review lenses

Walk the design through each lens; report only material findings:

1. Failure domains — What dies when each component dies? Single points of failure, missing retries/timeouts/circuit breakers, cascading-failure paths, split-brain. Trace the failure path of the money-critical flow specifically.
2. Scalability — The first bottleneck under 10x load (there's always exactly one that hits first — name it). Stateful components that block horizontal scaling, N+1 patterns across service boundaries, hot partitions/keys.
3. Data — Sources of truth (is each fact owned once?), consistency model vs. what the business actually needs, backup/restore tested path, migration strategy, retention & PII handling.
4. Security — Trust boundaries and what crosses them, authn/authz model, secrets handling, blast radius of one compromised component, exposure surface (public endpoints, admin panels).
5. Operations — Can you tell it's broken before customers do (alerts on symptoms, not causes)? Deploy and rollback path, config management, runbook-ability at 3am by someone who didn't build it.
6. Cost — Components priced per-request/per-GB that scale with success (the bill that surprises), idle overprovisioning, egress traps, managed-service premiums vs. their ops savings.
7. Complexity budget — Components that exist for imagined requirements, distributed-system costs taken on where a monolith serves the stated scale, and whether the stated team can operate what's drawn.