AI Prompts for System Architecture Design

Quick-Start (Copy This Right Now)

Are you designing a system architecture and facing the "blank whiteboard" problem — where the starting point is unclear and every choice seems like it could be wrong?

System architecture is one of the highest-stakes technical decisions a team makes. And it's also one of the best applications of AI prompts — not because AI knows your specific constraints, but because it can force you to articulate them and reason through them systematically.

Here's the starting prompt:

You are a systems architect. Help me design the architecture for the following system.

System requirements (functional):
[bullet list of what the system must do]

Non-functional requirements:
- Scale: [peak concurrent users / requests per second]
- Latency: [p99 acceptable latency for key operations]
- Availability: [99.9% / 99.99% / etc.]
- Data consistency: [eventual consistency acceptable? or must be strongly consistent?]
- Data volume: [estimate current and 2-year projected]

Team and operational constraints:
- Team size: [X engineers]
- Existing expertise: [languages, cloud provider, tools the team already knows]
- Budget: [approximate monthly infrastructure budget]
- Timeline to first deploy: [weeks/months]

Design a system architecture that meets these requirements. Include:
1. Component diagram (describe as text: boxes and arrows)
2. Key technology choices with brief justification
3. The main trade-offs you made and what you deprioritized
4. The single biggest risk in this architecture and how to mitigate it
5. What you'd do differently if the scale were 10× higher

What this does: Forces explicit articulation of non-functional requirements — the ones that most architecture discussions skip and then regret. Scale, latency, availability, and consistency are the four constraints that determine which architectural patterns are viable.

Understanding the Variables

"Data consistency: eventual vs strong" — this single decision has enormous downstream implications. Eventual consistency enables horizontal scaling at lower cost. Strong consistency simplifies programming models but limits scale options. Most architecture prompts don't ask about this — which means AI picks a consistency model without telling you it did.

"Existing expertise" — the technically optimal architecture for a team with no Kubernetes experience is not Kubernetes. AI often recommends advanced patterns without considering whether the team can operate them. Specifying existing expertise gets recommendations that the team can actually implement and maintain.

"The single biggest risk" — this is the highest-value element. Every architecture has a load-bearing assumption that, if wrong, requires significant rework. Getting the AI to name it explicitly gives you something to validate before you build.

⚡ Pro tip: After the initial architecture, ask: "Design the architecture you'd recommend if we needed to start with the simplest possible system and grow into this target architecture. What's the migration path?" Simple-to-complex architecture thinking prevents over-engineering on day one.

Step-by-Step: System Architecture with AI

Step 1: Define the boundaries before the internals.

Before choosing databases, services, or cloud providers, define what's in scope:

I'm designing a system for [purpose]. Before we get to implementation, help me define the system boundary. Answer:
1. What are all the external actors that interact with this system? (users, other services, external APIs, batch jobs)
2. What are all the data flows in and out of the system boundary?
3. What are the read-heavy vs write-heavy operations?
4. What operations are latency-sensitive vs can tolerate background processing?

Context: [describe your system in plain English]

What this does: Context diagrams precede component diagrams. Understanding the external interfaces before the internal structure prevents designing a beautiful internal architecture for the wrong interface.

Step 2: Choose the consistency and storage pattern.

For this system, help me choose the right data storage approach. The system handles:
- [describe your main data types and their relationships]
- [describe your most frequent read patterns]
- [describe your most frequent write patterns]

Compare for my use case:
1. A relational database (PostgreSQL)
2. A document database (MongoDB)
3. A hybrid approach (relational for transactions, document for flexible schema data)

Consider: query flexibility, consistency requirements, operational complexity for a [X]-person team, and cost at [N] records.

What this does: Database choice is one of the most consequential architecture decisions and one that's frequently made on preference rather than requirements. A comparison prompt forces requirements-based reasoning.

⚠️ Common mistake: Designing an architecture without specifying failure modes. Every component fails eventually. Add "for each component, describe what happens to the system when this component is unavailable" to any architecture review.

⚡ Pro tip: Ask for the "architecture decision records" alongside the design: "For each major technology choice, write a one-paragraph ADR (Architecture Decision Record) covering: the decision, the context, the alternatives considered, and why this choice was made. These should be committed to the repository as docs/adr/." ADRs are the institutional knowledge that architectural conversations produce but rarely preserve.

Pro-Level Variations

For event-driven architecture:

Design an event-driven architecture for this system. Specify: the events that flow between components (with payload schemas), the message broker choice (Kafka vs SQS vs RabbitMQ) with justification, how consumer groups handle parallel processing, how you handle event ordering requirements, and how you debug a production issue where an event was lost or processed incorrectly.

For microservices decomposition:

Help me decompose this monolith into microservices. Apply the principle of bounded contexts from Domain-Driven Design. For each proposed service: describe its responsibility, its data ownership (what tables/collections it owns), its external interface, and its dependencies on other services. Flag any proposed split that would require frequent cross-service transactions — these are signals of incorrect boundary placement.

For database scaling:

Design a database scaling strategy for this system as it grows from 1M to 100M records. Address in sequence: what to optimize first (indexes, query tuning), when to consider read replicas, when to consider caching, when to consider sharding, and what sharding key makes sense for the access patterns described. For each step, describe the migration path from the previous step.

Troubleshooting Common Issues

Problem: Architecture is too complex for the team. Fix: Add "this team has no dedicated DevOps engineer and limited operational experience. Prefer managed services over self-hosted infrastructure, even at higher cost."

Problem: AI recommends technologies the team doesn't know. Fix: Add "constrain technology choices to: [list your approved stack]. If a better option exists outside this list, note it but design within the constraint."

Problem: Architecture doesn't address the main scalability concern. Fix: Add "focus specifically on how this architecture handles [your specific concern: high write volume / large file processing / real-time updates / etc.] and what the bottleneck will be at 10× current load."

Your Turn

Architecture design is iterative — the first diagram is never the final design. Use AI as a sounding board through the iterations: propose a design, ask for the weakest point, refine, ask again. Each iteration captures more of the real constraints and produces a more defensible design.

PromptABCD is useful for storing your architecture prompt templates — the consistency questions, the ADR format, the failure mode analysis. Your ai prompts system architecture toolkit is the institutional memory of every architecture conversation your team has had.

Evolutionary Architecture

Systems change. An architecture that's correct today may be limiting in two years. Planning for evolution is as important as designing for current requirements.

Design this architecture with evolutionary principles in mind. Specifically:
1. Which components are most likely to change as requirements evolve? Design these with loose coupling and clear interfaces.
2. Which components are likely to be stable? These can be more tightly integrated.
3. What's the migration path if the chosen database doesn't scale to 10× current volume?
4. What's the migration path if we need to extract a microservice from the monolith in year 2?
5. Where are the "seams" — natural extension points where future requirements can be added without redesigning the core?

Architecture: [paste or describe your design]
Most likely future requirements: [describe 2-3 likely future needs]

What this does: Evolutionary architecture thinking identifies the decisions that are expensive to reverse early, and designs those areas for changeability from the start — without over-engineering areas that are unlikely to change.

⚡ Pro tip: For any architectural decision that feels like a significant commitment, ask: "What would we need to do to undo this decision in 12 months if it turns out to be wrong?" If the answer is "rewrite everything," that's a signal to either validate the decision more thoroughly before committing or find a more reversible alternative. Preferring reversible decisions early is one of the few architecture principles that applies across almost all contexts.

Architecture Documentation

Architecture decisions are valuable; architecture decisions that aren't documented become tribal knowledge that leaves with the engineer who made them.

Given this system architecture, write the following documentation:
1. A one-page architecture overview suitable for a new engineer joining the team
2. A C4 model description (Context, Containers, Components) in text format
3. The five most important architecture decisions made, as ADRs (Architecture Decision Records)
4. A "how this system handles failure" section covering each external dependency

Architecture: [describe]

⚡ Pro tip: For distributed systems, ask the AI to generate a chaos engineering runbook alongside the architecture: 'Given this architecture, write a chaos engineering experiment plan. For each critical component, describe: what failure to simulate, how to simulate it, what the expected system behavior is, and how to detect if the system behaves differently. Start with the most impactful and most likely failures first.' Chaos engineering runbooks written at design time are more comprehensive than those written after incidents — because you're thinking about what could go wrong, not just what did go wrong.

Saving this documentation prompt alongside your design prompts in PromptABCD means every architecture project ends with documentation, not just a decision. The ai prompts system architecture practice compounds when the decisions are written down.