Act as a senior software architect helping me evaluate and design a system. Context - Problem and users: [PROBLEM] - Existing system and constraints: [CURRENT SYSTEM] - Functional requirements: [FUNCTIONAL REQUIREMENTS] - Nonfunctional requirements: [NONFUNCTIONAL REQUIREMENTS] - Scale, data, and integrations: [SCALE AND INTEGRATIONS] - Decision constraints: [DECISION CONSTRAINTS] Ask up to 3 clarifying questions only if a required input is missing. Do not invent traffic figures, compliance obligations, vendor guarantees, data classifications, costs, or organizational capabilities. For security, privacy, legal, medical, or financial requirements, identify where specialist review is needed. Produce an architecture decision document with: 1) problem statement and explicit assumptions; 2) proposed architecture described in components and request/data flows; 3) responsibilities and interfaces for each component; 4) data ownership, lifecycle, retention, and consistency choices; 5) authentication, authorization, secret handling, audit logging, and threat considerations; 6) failure modes, retries, idempotency, observability, backups, and disaster recovery; 7) alternatives considered in a decision matrix; and 8) phased implementation plan with validation gates. Use an ASCII diagram only if it makes the component relationships clearer. Name concrete API boundaries, events, queues, caches, and database transactions only when warranted by the inputs. Distinguish a fact from an assumption and a recommendation. Include open questions and the decision owner for each. Self-check before answering: ensure every component solves a stated requirement or constraint, and identify any single point of failure, unbounded growth path, or authorization gap left unresolved.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PROBLEM] | Describe the business problem, users, and outcome the system must support. | Let store managers receive low-stock alerts and approve purchase orders from a web dashboard. |
| [CURRENT SYSTEM] | Describe the current architecture, codebase, deployment environment, and known limitations. | Rails monolith on PostgreSQL; nightly inventory imports from an ERP; managers already authenticate through Okta. |
| [FUNCTIONAL REQUIREMENTS] | List the capabilities and workflows the system must provide. | Show inventory by store, alert on reorder thresholds, create approval records, and sync approved orders to the ERP. |
| [NONFUNCTIONAL REQUIREMENTS] | List targets or expectations for reliability, latency, security, privacy, accessibility, and maintainability. | Alerts within 15 minutes of import, manager-only access by store, audit trail for approvals, and recovery from ERP outages. |
| [SCALE AND INTEGRATIONS] | State known usage volumes, data types, external systems, and expected growth. | 300 stores, 40,000 SKUs, nightly CSV imports today, ERP REST API for purchase orders. |
| [DECISION CONSTRAINTS] | List budget, deadline, team skills, vendor, compliance, or migration constraints. | Two Rails engineers, eight-week first release, retain the monolith unless a separate service is justified. |
How to use
- Replace the placeholders with facts, estimates labeled as estimates, and the decisions already made.
- Challenge the assumptions and alternatives section with engineering, security, and operations stakeholders.
- Turn the phased plan into tickets only after agreeing on interfaces and ownership.
- Follow up with: “Create an ADR for the recommended option and list the decisions that must be made this week.”
Variations
Architecture Review
Use when an existing design needs an independent risk assessment.
Review this architecture: [ARCHITECTURE DESCRIPTION OR DIAGRAM]. Evaluate it against [REQUIREMENTS], [SCALE], [SECURITY AND PRIVACY NEEDS], and [OPERATING CONSTRAINTS]. Return a prioritized risk register with the affected component, failure scenario, likelihood, impact, evidence, and smallest viable mitigation. Then identify architecture decisions that need explicit ownership. Do not assume undocumented controls exist. Ask up to 3 clarifying questions only if required context is missing.
Migration Plan
Use when moving from a legacy system without a risky cutover.
Design a migration from [LEGACY SYSTEM] to [TARGET SYSTEM] for [WORKFLOWS AND DATA], under [DOWNTIME LIMIT], [DATA INTEGRITY REQUIREMENTS], and [TEAM CONSTRAINTS]. Produce phases, data mapping and reconciliation, dual-write or backfill choices, feature-flag rollout, rollback triggers, observability, ownership, and user communication needs. Explain the main consistency risks. Do not invent data quality or traffic information. Ask up to 3 clarifying questions only if essential inputs are missing.
System Design Interview
Use when practicing a structured architecture interview answer.
Help me prepare a system-design answer for [SYSTEM TO DESIGN] with [EXPECTED SCALE], [KEY FEATURES], [INTERVIEW LEVEL], and [TIME LIMIT]. Give a timed outline: requirement questions, back-of-the-envelope estimates using labeled assumptions, API and data model, architecture, bottlenecks, reliability, and tradeoffs. Include likely interviewer follow-ups and concise answers. Do not claim real metrics or use unsupported capacity figures. Ask up to 3 clarifying questions only if a required input is missing.
Tips
- Start from data ownership and authorization boundaries; component diagrams without these decisions often conceal the hardest risks.
- Write down which requirements are measured versus assumed, especially latency, availability, and recovery targets.
- Choose the smallest architecture that meets the current constraint set, then document the signals that would justify adding complexity.
- A queue improves resilience only when you specify retry limits, dead-letter handling, idempotency, and how failures become visible to operators.
FAQ
Can AI choose the right architecture by itself?
It can structure options and expose tradeoffs, but the decision depends on your actual team, data, risks, and operating constraints.
Should every system use microservices?
No. Separate services add deployment, observability, ownership, and consistency costs; use them when those costs solve a real boundary or scaling need.
What makes an architecture proposal actionable?
It names interfaces, ownership, risks, decisions, and validation stages, rather than only listing technologies.