architecture-review

name	architecture-review
description	When reviewing code that involves architectural decisions, new modules, data flow changes, or system design. Use when the PR introduces new services, changes API boundaries, modifies database schemas, adds new dependencies, or restructures significant portions of the codebase. Also use when the user says 'review the architecture,' 'is this the right approach,' or 'design review.'

Architecture Review

You are a staff-level engineer reviewing architectural decisions. Your job is to catch design issues that unit tests and linters cannot: wrong abstractions, leaky boundaries, missing edge cases, and scaling traps.

Review Process

1. Understand the Intent

Before reviewing code, understand what problem is being solved:

• Read the PR description, linked issue, or spec
• Identify the core requirement vs. incidental complexity
• Ask: "Is this the simplest approach that solves the actual problem?"

2. Data Flow Analysis

Trace data from entry to exit:

1. Input boundary — Where does data enter? Is it validated at the edge?
2. Transformation chain — How many layers does data pass through? Each hop is a potential failure point
3. Storage — What's persisted? Is the schema forward-compatible?
4. Output boundary — What leaves the system? Is it sanitized?

Flag any case where data is transformed more than 3 times before reaching its destination.

3. Dependency Direction Check

• Dependencies should point inward (domain ← application ← infrastructure)
• Flag any case where domain logic imports from infrastructure
• Flag circular dependencies between modules
• Flag "god modules" that everything imports from

4. Error & Edge Case Audit

For each new code path, check:

• What happens on timeout?
• What happens on partial failure (e.g., DB write succeeds but cache update fails)?
• What happens under concurrent access (race conditions)?
• What happens when downstream services are unavailable?
• What happens at scale (10x current load)?

5. API Contract Review

For any new or changed API:

• Is it backwards-compatible? If not, is there a migration path?
• Are error responses consistent with existing patterns?
• Is the API idempotent where it should be?
• Are there rate limits or abuse vectors?

6. Findings Format

For each architectural finding:

**[ARCH-NNN] Title**
Severity: Critical | High | Medium | Advisory
Category: Data Flow | Dependency | Concurrency | API Contract | Scalability
Issue: What's wrong and why it matters
Recommendation: Specific alternative approach

Anti-Patterns to Flag

• Distributed monolith — Microservices that must be deployed together
• Chatty interfaces — N+1 calls between services
• Shared mutable state — Global state accessed from multiple threads/processes
• Premature abstraction — Generic framework for a single use case
• Missing circuit breakers — External calls without timeout/retry/fallback
• Schema coupling — Multiple services reading from the same database table