These 13 system design prompts help ChatGPT, Claude, Claude Code and Codex with real architecture work: turning a feature into requirements, estimating capacity, choosing data stores, designing caching and async processing, finding failure modes, setting SLOs, planning migrations, writing decision records and reviewing a design before you build it. They are written for systems you will run in production, not for interview practice.
For practice rounds, use the technical interview prompts. For endpoint and schema design, see the API design prompts.
How to use these prompts
Copy a prompt and fill the blanks in double braces. A blank with a colon has a default: {{scale:10k daily users}} means that unless you change it.
Give numbers, not adjectives. "High traffic" means nothing to a model. Requests per second at peak, data size after a year, the latency users notice and the downtime you can afford change the right design completely.
Include your constraints. Team size, existing stack, budget, compliance needs and what you already run in production all rule options in or out. A design that needs a team of twenty is wrong for a team of three, even if it's elegant.
Ask for trade-offs, not answers. Every prompt here asks for options and what each costs. The model's best value in system design is surfacing considerations, and you make the call.
How do you start a system design?
1. Turn a feature into requirements
Most design mistakes start with unclear requirements. This prompt makes the model ask before it designs.
I need to design {{system:a notification service for our SaaS app}}.
What I know: {{context}}
Before proposing anything, list the questions you need answered, grouped
into functional requirements, scale, latency, availability, consistency,
data retention, security and cost. Mark which answers would change the
design most. Then write a one-page requirements summary using my answers
where given and clearly labeled assumptions where not.
2. Estimate capacity
Back-of-the-envelope numbers decide whether you need one database or twenty.
Estimate capacity for {{system}}.
Inputs: {{inputs:50k daily active users, 20 actions each per day, 2 KB per record, peak is 5x average}}
Calculate: average and peak requests per second, read to write ratio,
storage per day and after {{years:3}} years including indexes and replicas,
and bandwidth. Show each step so I can check the math. Then say which
numbers are big enough to drive design choices and which are small enough
to ignore.
3. Draft a high-level design
Propose a high-level design for {{system}}.
Requirements: {{requirements}}
Constraints: {{constraints:team of 4, AWS, PostgreSQL already in use, small budget}}
Give me: the main components and what each owns, the data flow for the
two most important use cases step by step, where state lives, and what
runs synchronously versus asynchronously. Start with the simplest design
that meets the requirements, then list what you would add only if a
specific number grows, and which number.
4. Describe the design as C4 diagrams
The C4 model defines four levels of diagram: system context, container, component and code. Its diagrams page says the system context and container diagrams are sufficient for most software development teams.
Describe this design as C4 model diagrams:
{{design}}
Write a system context diagram (users and external systems) and a
container diagram (applications, data stores and how they talk, with
protocols). Output each as {{format:Mermaid}} code with a short legend.
Only add a component diagram for {{focus:the part that changes most}}.
Keep labels short and name the technology on each container.
How do you choose data stores, caching and queues?
5. Choose a data store
Help me choose a data store for {{data:user activity events}}.
Access patterns: {{patterns:append-heavy writes, reads by user and time range, occasional analytics}}
Size and growth: {{size}}
Consistency needs: {{consistency}}
What we already run: {{existing:PostgreSQL}}
Compare {{count:3}} realistic options in a table: fit for each access
pattern, consistency, operations burden, cost at our size, and what breaks
first as we grow. Recommend one and say what would make you change your
mind. Prefer what we already run unless it clearly fails a requirement.
6. Design a caching layer
The cloud design patterns catalog in the Azure Architecture Center describes Cache-Aside as loading data on demand into a cache from a data store. This prompt picks the pattern and works through invalidation.
Design caching for {{feature:product pages and prices}}.
Read and write rates: {{rates}}
How stale data can be: {{staleness:product text 10 minutes, prices must be current}}
Decide what to cache and where (CDN, application, distributed cache),
the pattern (cache-aside, read-through, write-through), keys, TTLs and how
writes invalidate entries. Cover cache stampedes on popular keys, cold
starts after a deploy, and what happens when the cache is down. Show the
read and write paths step by step.
7. Move work to a queue
This request does too much work inline and times out under load:
{{flow}}
Redesign it with asynchronous processing. Decide what must stay
synchronous for the user and what can move to a queue. Specify message
contents, retries with backoff, a dead-letter queue, idempotent consumers
so duplicates are safe, ordering needs, and how the user learns the result
(polling, webhook or push). List the new failure modes this introduces.
How do you plan for failure and scale?
8. Find failure modes
The Azure catalog suggests pairing Retry with Circuit Breaker so an application retries transient faults but stops when a fault persists. This prompt checks every dependency for that kind of gap.
List the failure modes of this design:
{{design}}
For each component and dependency, ask: what if it is slow, down, returns
errors, returns wrong data, or is overloaded? For each failure give the
user impact, how we detect it, and the mitigation (timeouts, retries with
backoff, circuit breaker, bulkhead, fallback, graceful degradation). Rank
by likelihood times impact and point out any single point of failure.
9. Set SLIs and SLOs
Google's SRE book defines an SLO as "a target value or range of values for a service level that is measured by an SLI," and advises looking at latency as a distribution rather than an average.
Define SLIs and SLOs for {{service:our public checkout API}}.
What users care about: {{user_needs:checkout succeeds and feels fast}}
Current numbers if known: {{current}}
Propose 2 to 4 SLIs (precise definitions: what is measured, where, and
which requests count), an SLO for each with a time window, and the error
budget that results. Use percentiles for latency, not averages. Suggest an
internal target tighter than anything we publish, and what the team does
when the error budget runs out.
10. Plan for 10x growth
Our system handles {{current:200 requests per second at peak}} today. Plan
for {{target:2,000}}.
Architecture: {{design}}
Current bottlenecks we know of: {{bottlenecks}}
Identify what breaks first, second and third as load grows, with the
number at which each breaks and how you estimated it. For each, give the
cheapest fix and the more durable fix. Say what to load test and which
metrics to watch so we see each limit coming before users do.
How do you migrate and document a design?
11. Plan an incremental migration
The Azure catalog describes the Strangler Fig pattern as migrating a legacy system "by gradually replacing pieces of functionality with new applications and services."
Plan a migration from {{from:a monolith}} to {{to:separate billing and notification services}}.
Current system: {{current}}
Must not break: {{invariants:billing accuracy, existing API clients}}
Use small, reversible steps. For each step: what moves, how traffic or
data is routed during the move, how we verify it (shadow traffic, dual
writes with comparison, feature flags), and how we roll back. Cover data
migration and keeping both sides consistent. End with what we can delete
after each step.
12. Write an architecture decision record
Michael Nygard's Documenting Architecture Decisions post proposes a short record with a title, context, decision, status and consequences.
Write an architecture decision record from these notes:
{{notes}}
Use the sections Title, Status ({{status:proposed}}), Context, Decision
and Consequences. Context states the forces and facts without arguing for
the answer. Decision starts with "We will". Consequences lists positive,
negative and neutral effects, including what becomes harder. Add the
options we rejected and why in one line each. Keep it under one page.
13. Review a design doc before building
The AWS Well-Architected Framework names six pillars: operational excellence, security, reliability, performance efficiency, cost optimization and sustainability.
Review this design doc as a senior engineer who will be on call for it:
{{design_doc}}
Check it against the six Well-Architected pillars: operational excellence,
security, reliability, performance efficiency, cost optimization and
sustainability. Then check: unstated assumptions, missing numbers, data
consistency gaps, migration and rollback, observability, and what happens
at 10x load. Output the top five risks ranked, each with a question the
author must answer before building.
How do you get better system design answers from AI?
Work in rounds. Start with the requirements prompt, answer its questions, then run the high-level design prompt with those answers pasted in. Follow with failure modes and the design review. Each round gives the model more real context, and the final design is better than a single giant prompt would produce. Save the ADRs in your repo next to the code they describe.
Check the math yourself. Models make arithmetic slips in capacity estimates, and one wrong zero changes the design. Ask the model to show every step, then rerun the key numbers in a spreadsheet. Be equally skeptical of confident claims about a specific product's limits or prices: verify them in the vendor's own documentation before they go into a design doc.
The architecture patterns skill, documentation and ADRs skill and improve codebase architecture skill pages cover ready-made skills for this kind of work. To turn your own review checklist into a skill, paste it into the SKILL.md generator.
Kipt keeps prompts like these as Markdown in a private GitHub repo you own, with {{scale:10k daily users}} style blanks, tags and Cmd+K search, so your design review checklist is one search away. Skills you save there install into Claude Code or Codex with one command.