System Design Prompt Builder

System design prompt builder

A good system design answer is not a diagram — it is a chain of reasoning: clarify the requirements, propose an architecture, size it for the stated scale, find the bottlenecks, and name the trade-offs you accepted. LLMs can produce that chain well, but only when the prompt forces the structure and supplies real numbers. This builder turns your system, scale, and priorities into a prompt that demands a complete, scale-aware design with explicit trade-offs — useful for interview practice and for real first-pass architecture alike.

How it works

You describe the system, enter scale requirements (users, QPS, data volume), choose your CAP-theorem priority, and list constraints or components to focus on. The tool assembles a prompt that walks the model through the canonical phases: restate and clarify requirements, sketch a high-level architecture, define the API and data model, present a scaling strategy that meets the stated load, analyze bottlenecks, and lay out the key trade-offs given your CAP choice. You pick the output format (prose, sectioned, or with a textual diagram). Everything runs locally until you paste it into your LLM.

How scale numbers change the design

The system design changes substantially at different scale points. Providing concrete numbers is what allows the model to recommend the right tier of solution, rather than a generic “add a cache and load balancer” answer:

These ranges are illustrative — real thresholds depend on read/write ratio, data size, and access pattern. The point is that the model cannot reason about caching, sharding, or queue depth without some order-of-magnitude figure. “High traffic” is not a scale requirement.

CAP theorem in practice: which side to favor

Under network partition (the P in CAP), a distributed system must choose between consistency and availability. This choice determines the recommended database and replication strategy:

• Favor consistency (CP): Banking, payments, inventory management, healthcare records. Examples: PostgreSQL with synchronous replication, Google Spanner, CockroachDB.
• Favor availability (AP): Social feeds, analytics dashboards, search, content delivery. Examples: Cassandra, DynamoDB, Redis Cluster.

The prompt will ask the model to justify its data store choice against your stated CAP preference, which is exactly the reasoning a good interview answer or design review needs to show.

What a complete system design answer covers

The prompt asks the model to walk through all six canonical phases:

1. Clarify requirements — functional (what it does) and non-functional (latency, availability, scale)
2. High-level architecture — components and their relationships at a diagram level
3. API and data model — key endpoints and the schema for the core entities
4. Scaling strategy — how the design handles the stated load
5. Bottleneck analysis — where failures or performance problems will first appear
6. Trade-offs — what the chosen approach gives up and why that is acceptable

Missing any of these is where most design answers — interview or otherwise — lose points. The prompt enforces coverage of all six.

Tips and notes

• Give real numbers. “100M users, 80k QPS peak, 10TB/year” lets the model size shards and caches; without them the design stays generic.
• Pick a CAP side. A payments ledger favors consistency; a social feed favors availability. Stating it changes the recommended data store.
• Focus the components. If you only care about the write path or the caching layer, list it — the prompt will go deep there instead of spreading thin.
• Ask for trade-offs explicitly. The best designs name what they gave up; the prompt requires this so you do not get an over-confident single answer.