ChatGPT Software Architecture Planner Prompt
Design a scalable software architecture with component breakdown, data flow, and technology decisions.
Category
💻 Coding
Difficulty
Advanced
Models
3
Last Updated
2026-06-28
Works with
📄 Example output
⚠️ Common Mistakes
❓ FAQ
⚙️ Fill in your variables
📋 Prompt
You are a principal software engineer with 15+ years of experience designing systems that scale from 0 to millions of users.
Project: [project description]
Scale target: [scale target — personal project/1,000 users/100,000 users/1M+ users]
Stack preference: [stack preference — Python/Node.js/Go/no preference]
Deployment: [deployment — single server/cloud/serverless/edge]
Task: Design a complete software architecture:
1. ARCHITECTURE OVERVIEW:
- System type (monolith/modular monolith/microservices/serverless)
- Rationale for this choice at your scale
- When to reconsider this architecture
2. COMPONENT BREAKDOWN:
For each component:
- Name and responsibility
- Technology choice and why
- Interface (API/event/shared memory)
- Failure mode and mitigation
3. DATA ARCHITECTURE:
- Database choice and schema approach
- Caching strategy
- Data flow diagram (text-based)
4. API DESIGN PRINCIPLES:
- REST vs. GraphQL vs. gRPC decision
- Versioning strategy
- Authentication approach
5. SCALABILITY PATH:
- What breaks first at 10× current load
- The one change to make before that happens
6. SECURITY CHECKLIST:
10 security considerations for this specific architecture
7. MONITORING STRATEGY:
What to measure + alerting thresholds
Format: Architecture diagram as ASCII art or text-based flow. Decision tables where appropriate.
Project: [project description]
Scale target: [scale target — personal project/1,000 users/100,000 users/1M+ users]
Stack preference: [stack preference — Python/Node.js/Go/no preference]
Deployment: [deployment — single server/cloud/serverless/edge]
Task: Design a complete software architecture:
1. ARCHITECTURE OVERVIEW:
- System type (monolith/modular monolith/microservices/serverless)
- Rationale for this choice at your scale
- When to reconsider this architecture
2. COMPONENT BREAKDOWN:
For each component:
- Name and responsibility
- Technology choice and why
- Interface (API/event/shared memory)
- Failure mode and mitigation
3. DATA ARCHITECTURE:
- Database choice and schema approach
- Caching strategy
- Data flow diagram (text-based)
4. API DESIGN PRINCIPLES:
- REST vs. GraphQL vs. gRPC decision
- Versioning strategy
- Authentication approach
5. SCALABILITY PATH:
- What breaks first at 10× current load
- The one change to make before that happens
6. SECURITY CHECKLIST:
10 security considerations for this specific architecture
7. MONITORING STRATEGY:
What to measure + alerting thresholds
Format: Architecture diagram as ASCII art or text-based flow. Decision tables where appropriate.
ARCHITECTURE: ToolsNova AI Prompt Library
Scale: 100K MAU | Stack: Python generator + Cloudflare Pages + KV Store
ARCHITECTURE CHOICE: Pre-rendered Static + Edge Functions
Rationale: At 100K MAU with read-heavy, low-write content (prompts don't change hourly), pre-generated HTML is the correct choice. Zero server costs, instant load times globally, zero scaling concerns for read traffic. Use Cloudflare Workers (edge functions) only for truly dynamic features.
When to reconsider: When you need real-time personalisation, user-generated content at scale, or content that changes faster than your build time allows.
COMPONENT BREAKDOWN:
[User Browser]
↓
[Cloudflare Edge] ← serves pre-built HTML/CSS/JS
↓ (dynamic requests only)
[Cloudflare Workers] ← handles: search suggestions, saved favourites sync
↓
[Cloudflare KV Store] ← stores: user preferences, recently viewed
[GitHub Repository]
↓ (on push)
[Python Generator (generator.py)] → builds 300+ HTML pages
↓
[Cloudflare Pages] ← auto-deploys on push
DATA ARCHITECTURE:
Static data (prompts, categories, models): JSON files in /data/*
Generation: Python reads JSON → writes HTML at build time
User state: localStorage only (favorites, recently viewed) — no server needed
Search: Client-side search on pre-loaded JSON index (< 100KB for 1,000 prompts)
SCALABILITY PATH:
What breaks first: The client-side search JSON index grows proportionally with prompts. At 5,000 prompts, the search index is ~500KB — still fine.
At 10,000+ prompts: Switch to Pagefind (static search library) which indexes at build time and loads search results lazily. Zero backend required.
SECURITY CHECKLIST:
1. No user authentication = no auth vulnerabilities
2. Content Security Policy headers via Cloudflare
3. No server-side code = no SQL injection / XSS server-side
4. localStorage only — no PII stored server-side
5. Build process: validate all JSON before generating HTML
...
Scale: 100K MAU | Stack: Python generator + Cloudflare Pages + KV Store
ARCHITECTURE CHOICE: Pre-rendered Static + Edge Functions
Rationale: At 100K MAU with read-heavy, low-write content (prompts don't change hourly), pre-generated HTML is the correct choice. Zero server costs, instant load times globally, zero scaling concerns for read traffic. Use Cloudflare Workers (edge functions) only for truly dynamic features.
When to reconsider: When you need real-time personalisation, user-generated content at scale, or content that changes faster than your build time allows.
COMPONENT BREAKDOWN:
[User Browser]
↓
[Cloudflare Edge] ← serves pre-built HTML/CSS/JS
↓ (dynamic requests only)
[Cloudflare Workers] ← handles: search suggestions, saved favourites sync
↓
[Cloudflare KV Store] ← stores: user preferences, recently viewed
[GitHub Repository]
↓ (on push)
[Python Generator (generator.py)] → builds 300+ HTML pages
↓
[Cloudflare Pages] ← auto-deploys on push
DATA ARCHITECTURE:
Static data (prompts, categories, models): JSON files in /data/*
Generation: Python reads JSON → writes HTML at build time
User state: localStorage only (favorites, recently viewed) — no server needed
Search: Client-side search on pre-loaded JSON index (< 100KB for 1,000 prompts)
SCALABILITY PATH:
What breaks first: The client-side search JSON index grows proportionally with prompts. At 5,000 prompts, the search index is ~500KB — still fine.
At 10,000+ prompts: Switch to Pagefind (static search library) which indexes at build time and loads search results lazily. Zero backend required.
SECURITY CHECKLIST:
1. No user authentication = no auth vulnerabilities
2. Content Security Policy headers via Cloudflare
3. No server-side code = no SQL injection / XSS server-side
4. localStorage only — no PII stored server-side
5. Build process: validate all JSON before generating HTML
...
🏆
💡 Pro Tips
Best model for this prompt
Claude
Claude (Opus 4 / Sonnet 4)
Choose the simplest architecture that meets your scale requirement — most projects are over-architected, not under-architected
Design for the failure mode, not the happy path — the question to ask for every component is 'what happens when this breaks?'
Premature optimisation kills more projects than insufficient architecture — build a working monolith first, then extract services when the pain is real
Write Architecture Decision Records (ADRs) for every significant technical decision — future-you will be grateful
Designing for 10M users when you have 10 — microservices at this scale create enormous operational overhead with no benefit
No caching strategy — adding a cache is often the highest-leverage performance improvement available at any scale
Shared database across multiple services — this is the most common microservices mistake and creates tight coupling
No monitoring from day one — you can't fix what you can't measure
- Monolith or microservices?Start with a monolith. Always. Even Netflix and Amazon started as monoliths. Microservices solve problems that arise from scale and team size — they create problems at small scale. Extract services when: (1) teams need to deploy independently, (2) a component has genuinely different scaling requirements, (3) the monolith is hard to change safely.
- SQL or NoSQL?SQL (PostgreSQL) for most projects — it's more flexible, better supported, ACID compliant, and handles most use cases extremely well. NoSQL (MongoDB, DynamoDB) for: extreme horizontal write scale, variable schemas at large volumes, or geographically distributed data. Don't choose NoSQL to avoid learning SQL.
- Which AI model is best for architecture planning?Claude is strongest for system design — it maintains coherent system thinking across a complex multi-component architecture, reasons well about trade-offs and failure modes, and produces better-structured ADRs. DeepSeek is strong for specific technology comparisons and code-level architecture decisions.
- How do I document architecture for future team members?Architecture Decision Records (ADRs): short documents explaining what was decided, why, and what alternatives were considered. C4 diagrams: four levels (Context → Container → Component → Code) using simple tools like Mermaid or PlantUML. These two tools together handle 90% of architecture documentation needs.