Architecture Review with Trade-off Analysis

What it does

Reviews a system architecture the way a principal engineer would during a design review: by identifying the actual trade-offs being made, not just listing violations of best practices. Every architecture makes trade-offs. This prompt surfaces them explicitly so you can decide whether you’re making the right ones for your constraints.

The Prompt

Review the following system architecture. Focus on trade-offs, not ideals.

System description:
[DESCRIBE YOUR SYSTEM — components, data flow, key interactions. Include a diagram if you have one, or describe the architecture in words: "Service A calls Service B via REST, which writes to Postgres and publishes to Kafka..."]

Scale context:
[CURRENT AND EXPECTED SCALE — requests/sec, data volume, team size, deployment frequency]

Primary quality attribute:
[WHAT MATTERS MOST — availability, latency, throughput, developer velocity, cost, data consistency. Pick ONE as primary, optionally rank 2-3 others.]

Review structure:

1. ARCHITECTURE SUMMARY: Restate the architecture in your own words. Identify the core architectural pattern (monolith, microservices, event-driven, CQRS, etc.) and the implicit assumptions it makes about scale, team, and change frequency.

2. TRADE-OFF ANALYSIS: For each major architectural decision, identify:
   - What it optimizes FOR (the benefit you're getting)
   - What it optimizes AGAINST (the cost you're paying)
   - Whether this trade-off is appropriate given the stated scale and quality priorities
   Format: "Decision: [X] → Gains: [Y] at the cost of: [Z] → Appropriate: yes/no/depends"

3. FAILURE MODES: Identify the 3 most likely failure scenarios at stated scale. For each:
   - Trigger condition
   - Blast radius (what breaks, what keeps working)
   - Recovery path (automatic vs manual, time estimate)
   - Whether the current architecture handles it or not

4. SCALING BOTTLENECKS: Identify where this architecture will hit limits FIRST as scale increases. Be specific: "Postgres will hit write throughput limits at ~5k writes/sec because of the single-writer pattern on the orders table."

5. RECOMMENDATIONS: Maximum 5 changes, each with:
   - Priority: P0 (fix now) / P1 (fix before next scale milestone) / P2 (tech debt, schedule it)
   - Effort: hours / days / weeks
   - What it unblocks or prevents

Do NOT recommend microservices, Kubernetes, or event sourcing as default answers. Recommend only what the stated constraints justify.

Usage Notes

• The “do NOT recommend microservices as default” instruction is critical. Without it, every architecture review converges on the same generic advice regardless of actual needs.
• Provide real numbers in the scale context. “We expect growth” is useless. “We’re at 200 req/sec, expecting 2000 in 6 months” gives the model something to reason about.
• The trade-off format forces explicit reasoning: if you can’t articulate what a decision costs you, you haven’t evaluated it properly.
• Works best with Claude or GPT-4+ models for complex systems. For simpler architectures, any model works.
• Pair with the Migration Planner prompt if the review reveals a needed architectural change.