Generic system design interview prompts waste tokens and produce vague answers. These three templates force any LLM to give you a structured, actionable design document instead.
System Design Prompts That Actually Work
I've spent months testing "System Design Prompts" across Claude, GPT-4, Gemini, and DeepSeek. The difference between a usable design and a textbook dump comes down to how you constrain the response. Generic prompts like "design a URL shortener" get you generic output. These templates below force the model to make decisions, not just list options.
Why Generic Prompts Fail Here
The core problem: LLMs default to the most common answer, not the best answer for your constraints. Ask for a "chat system" and you'll get WebSocket architecture with Redis pub/sub — even if you're building for 50 users, not 50 million.
Generic prompts also skip the hard parts. They'll happily describe sharding strategies but never ask about your data consistency requirements, your team's operational capacity, or your actual cost ceiling. The templates below fix this by forcing the model to state assumptions, make trade-offs, and defend choices.
Template 1: The Constraint-First Design
This works best for greenfield systems where you need a complete architecture in one shot.
You are a staff engineer reviewing a design for [SYSTEM NAME].
Requirements:
- Scale: [CONCURRENT_USERS] concurrent users, [QPS] peak read QPS, [WRITE_QPS] peak write QPS
- Data: [DATA_MODEL_DESCRIPTION], [DATA_VOLUME] total storage, [RETENTION_PERIOD] retention
- Consistency: [STRONG/EVENTUAL] consistency required for [SPECIFIC_OPERATIONS]
- Budget: [MONTHLY_INFRA_BUDGET] cloud spend, [TEAM_SIZE] engineers to operate it
- Latency: [P95_LATENCY_TARGET] p95 latency for reads, [WRITE_LATENCY] for writes
Deliver the following in exactly this order:
1. State 3 critical assumptions about the workload that would invalidate this design
2. A mermaid diagram of the high-level architecture with 5-8 components max
3. The top 3 bottlenecks at 10x the stated scale, and how you'd mitigate each
4. What you'd cut from this design if the budget were halved
5. One alternative architecture you rejected and why
Do not include: security hardening details, deployment pipeline specifics, or monitoring setup — those are separate concerns.
Placeholder meanings:
[SYSTEM NAME]— the actual product (e.g., "a ride-sharing dispatch system")[CONCURRENT_USERS]— be honest, not aspirational[QPS]— use real numbers from your current logs or traffic estimates[DATA_MODEL_DESCRIPTION]— "time-series events," "user profiles with 50 fields," etc.[MONTHLY_INFRA_BUDGET]— forces the model to pick cheaper options
Template 2: The Migration/Refactor Design
For when you're not starting from scratch — you're moving an existing system or fixing a broken one.
You are helping me modernize [EXISTING_SYSTEM] currently running on [CURRENT_STACK] with [CURRENT_SCALE] scale.
Known issues:
- [PAIN_POINT_1] (e.g., "database locks during peak hours")
- [PAIN_POINT_2] (e.g., "deploys take 45 minutes")
- [PAIN_POINT_3] (e.g., "can't scale reads horizontally")
Constraints:
- Cannot rewrite: [NON_NEGOTIABLE_COMPONENTS] must stay as-is
- Migration window: [TIME_WINDOW] per month for cutover
- Rollback plan required if [SPECIFIC_FAILURE_CONDITION] happens
Produce:
1. A strangler-fig migration plan with 4-6 phases, each independently deployable
2. For each phase: what breaks, what the rollback looks like, and how you verify success
3. A mermaid sequence diagram showing request flow before and after phase 3
4. The single highest-risk change and how you'd de-risk it first
5. What you'd tell the CTO if they asked for this in half the time
This template shines because it forces sequencing. Most LLM responses treat migrations as a single big-bang event. This prompt makes the model think in deployable increments, which is how real systems actually change.
Template 3: The Failure-Mode Autopsy
For when you have an existing design (yours or the LLM's) and want to break it before production does.
Here is a system design for [SYSTEM_NAME]:
[DESIGN_SUMMARY_OR_PASTE_LLM_OUTPUT]
Your job is to find the 5 most likely ways this design fails in production. For each failure:
1. Name the failure mode (e.g., "thundering herd on cache invalidation")
2. Describe the specific trigger scenario (be concrete: "3 cache nodes restart simultaneously during a deploy")
3. Trace the cascade: what breaks first, then what breaks because of that
4. Rate severity (1-5) and likelihood (1-5)
5. Give the minimal fix that prevents it — not a redesign, just the patch
Then answer: if I told you this design was already in production and p99 latency just spiked 10x, what's the first thing you'd check? Give me a decision tree, not a list.
Finally, tell me what single metric I should alert on that would have caught this earliest.
This is the hardest template for LLMs to fake. They'll try to give generic failure modes (database down, network partition). The prompt forces them to work backward from your specific design. I've found Claude and GPT-4 do best here; DeepSeek sometimes gives shallower cascade analyses.
How to Adapt These for Your Own Codebase
Stop copying prompts verbatim. The placeholder values are what make them work. Spend 15 minutes gathering real numbers before you start — your actual QPS, real p99 latency, current cloud spend. Garbage numbers in, garbage design out.
Also, iterate. Run the same template twice with slightly different constraints (e.g., "budget halved" vs. "scale doubled") and compare. The differences in the model's choices teach you more than either output alone.
For codebase-specific details, append a context block after the template: "Our stack is [LANGUAGE] on [FRAMEWORK], we use [DATABASE], and our team has [SKILLS]." The model will tailor its recommendations to what your team can actually build.
Do These Prompts Work With Any LLM?
Mostly, but with caveats. Claude 3.5 Sonnet and GPT-4 give the best structured outputs and follow formatting instructions reliably. Gemini is good at the mermaid diagrams but sometimes drifts from the required order. DeepSeek handles the constraint-first template well but produces weaker failure-mode analyses in Template 3.
The templates work because they're explicit about output format. If your model ignores the "exactly this order" instruction, add "Number each section" to the prompt — that alone fixes 90% of formatting drift. For code generation within designs, GPT-4 and Claude are still ahead; DeepSeek's code is functional but less idiomatic.
The single adjustment that improves these prompts the most: add "If any constraint is unrealistic or conflicts with another, say so and propose a revised constraint before proceeding." This forces the model to validate your assumptions instead of blindly designing around impossible requirements.