AI prompts for system design help US software engineers and architects reason through the classic questions — how do we build a URL shortener at 10K QPS, how do we shard the user table, where does the cache live, what fails first when the DB primary goes down — without staring at a blank whiteboard. Every template below produces the structured artifact a real design review expects: capacity math, an API surface, a data model, failure modes, and the trade-offs that separate a strong design from a plausible one.
These templates assume mainstream US industry context: AWS/GCP/Azure primitives, PostgreSQL and DynamoDB as default OLTP stores, Redis and Memcached as caches, Kafka and SQS for queues, and SRE-inspired SLO/SLI/SLA vocabulary. Numbers are given in QPS, p50/p95/p99 latency, and TB/PB rather than vague adjectives. Where trade-offs exist — SQL vs. NoSQL, push vs. pull fanout, token bucket vs. sliding window — the prompts ask the AI to actually pick a side and defend it, not to enumerate options and shrug.
This content is a design-thinking aid, not an architecture rubber stamp. Any design that touches money, PII, PHI, safety-critical paths, or multi-region failover needs human review by an engineer accountable for the system. Use AI to draft the capacity estimate, the API sketch, and the ADR — then defend the design in a real review with people who will operate it at 3 AM.
AI prompts for system design help US software engineers and architects reason through the classic questions — how do we build a URL shortener at 10K QPS, how do we shard the user table, where does the cache live, what fails first when the DB primary goes down — without staring at a blank whiteboard. Every template below produces the structured artifact a real design review expects: capacity math, an API surface, a data model, failure modes, and the trade-offs that separate a strong design from a plausible one.
These templates assume mainstream US industry context: AWS/GCP/Azure primitives, PostgreSQL and DynamoDB as default OLTP stores, Redis and Memcached as caches, Kafka and SQS for queues, and SRE-inspired SLO/SLI/SLA vocabulary. Numbers are given in QPS, p50/p95/p99 latency, and TB/PB rather than vague adjectives. Where trade-offs exist — SQL vs. NoSQL, push vs. pull fanout, token bucket vs. sliding window — the prompts ask the AI to actually pick a side and defend it, not to enumerate options and shrug.
This content is a design-thinking aid, not an architecture rubber stamp. Any design that touches money, PII, PHI, safety-critical paths, or multi-region failover needs human review by an engineer accountable for the system. Use AI to draft the capacity estimate, the API sketch, and the ADR — then defend the design in a real review with people who will operate it at 3 AM.
Guides, tips, and deep dives for this prompt category
Create stunning Studio Ghibli-style AI art with 50 free prompts for ChatGPT. Magical landscapes, characters, food scenes, and cozy interiors in Miyazaki style.
Read moreCollectionGenerate stunning, unique tattoo designs using AI. 50 free copy-paste prompts for Midjourney, ChatGPT, Gemini & Stable Diffusion. Minimal, geometric, Japanese, floral & more styles.
Read moreCopy any prompt below, paste into ChatGPT, Claude, Gemini, or Copilot, and fill in the placeholders in [brackets].
Act as a US senior software engineer. Design a URL shortener at [scale: e.g., 100M new URLs/month, 10B total, 20K read QPS, 500 write QPS] with p99 < 100ms redirect latency. Cover capacity estimation (QPS, storage, bandwidth), API design (POST /shorten, GET /:code) with request/response JSON, data model with short-code generation strategy, and cache layer sizing.
Act as a US senior software engineer. Design a chat application for [N: e.g., 10M DAU, 500 msg/user/day] with real-time delivery (< 500ms p99), read receipts, and 90-day message retention. Cover WebSocket vs. long-poll trade-off, message store (Cassandra vs. DynamoDB), fanout to online recipients, offline delivery via push notifications, and presence tracking.
Act as a US senior software engineer. Design a social newsfeed for [N: e.g., 50M DAU, 200 followers avg, 5 posts/user/day, 90/10 read/write]. Compare push (fanout-on-write), pull (fanout-on-read), and hybrid strategies. Pick one and justify it based on celebrity-user skew, timeline latency budget, and write-amplification. Include data model and cache sizing.
Act as a US senior software engineer. Do capacity estimation for [service: e.g., image upload API] with [inputs: 5M DAU, 3 uploads/user/day, avg 2MB image, 5% peak factor, 1-year retention, 3× replication]. Show QPS (steady and peak), storage/year, bandwidth ingress/egress, and CPU-bound vs. IO-bound assessment. Round aggressively and show the arithmetic.
Act as a US senior software engineer. Design the API for [resource: e.g., a Payments resource] as both REST and GraphQL. For REST: list endpoints with methods, path parameters, request/response JSON, status codes, and pagination. For GraphQL: schema with types, queries, mutations, and connection-based pagination. Recommend which fits the workload and why.
Act as a US senior software engineer. Design a database schema for [entity: e.g., a multi-tenant SaaS billing system with Accounts, Subscriptions, Invoices, LineItems, Payments]. Include table definitions with primary keys, foreign keys, indexes (including partial and covering indexes), and a note on how tenant isolation is enforced (shared schema + tenant_id vs. schema-per-tenant).
Act as a US senior software engineer. Decide SQL vs. NoSQL for [use case: e.g., a product catalog with 10M SKUs, faceted search, seller-managed attribute schemas, and 5K read QPS]. Enumerate the top 5 requirements, score PostgreSQL and DynamoDB against each, pick a winner, and explain the migration path if the workload later shifts.
Act as a US senior software engineer. Design a caching strategy for [read pattern: e.g., product detail page with 90/10 read/write, 10K QPS peak, 500KB payload, 5-minute freshness tolerance]. Choose between cache-aside, read-through, write-through, and write-behind. Specify TTL, eviction policy (LRU vs. LFU), stampede protection, and how you handle cache invalidation on writes.
Act as a US senior software engineer. Design rate limiting for [API: e.g., a public POST /messages endpoint with 100 req/min/user, 10K req/min/tenant, and abuse protection]. Compare token bucket, leaky bucket, fixed window, and sliding window log/counter. Pick one, specify where it runs (edge vs. app), the storage (Redis Lua scripts vs. local memory), and behavior at the limit (429 with Retry-After).
Act as a US senior software engineer. Enumerate failure modes for [system: e.g., a checkout service depending on Postgres, Redis, Stripe, and an internal Inventory service]. For each dependency, list the failure (slow, unavailable, corrupted), detection signal, blast radius, and mitigation (timeout, retry with backoff, circuit breaker, fallback, degraded mode). Include a table of the top 8.
Act as a US senior software engineer. Write an observability plan for [service: e.g., a payments API]. Cover: structured logs (JSON with trace ID, tenant ID, request ID), RED metrics (Rate, Errors, Duration) and USE metrics (Utilization, Saturation, Errors) with example Prometheus queries, distributed tracing (OpenTelemetry spans across service boundaries), and 3 SLOs with SLIs and error budgets.
Act as a US senior software engineer. Write a disaster recovery plan for [system: e.g., a multi-tenant SaaS on AWS, single-region us-east-1, PostgreSQL RDS Multi-AZ, S3 storage]. Specify RTO and RPO targets, backup strategy (frequency, retention, cross-region copy), failover runbook, DR test cadence, and what breaks first if us-east-1 goes down completely. Include a 4-column risk table.
Act as a US senior software engineer. Walk through a system design interview answer for [problem: e.g., design a rideshare matching service, design a distributed job scheduler, design a stock ticker]. Use the standard structure: clarify requirements (functional + non-functional), estimate scale, sketch API, design data model, propose architecture, discuss trade-offs, cover failure modes, and end with 'what I would build next.'
Act as a US senior software engineer. Draft an Architecture Decision Record (ADR) using the standard template: Title, Status (Proposed/Accepted/Superseded), Context, Decision Drivers, Options Considered (3–4 with pros/cons), Decision, Consequences (positive and negative), and Follow-ups. Use [decision: e.g., 'ADR-0007: Adopt DynamoDB for session storage instead of Redis'] as the concrete example.
Understanding the building blocks lets you adapt any prompt to your own creative direction.
Tell the AI who the output is for and what real workplace situation it should support.
Act as a federal program analyst preparing a plain-language memo for agency leadership.Name the exact deliverable: email, memo, checklist, SOP, meeting recap, training note, or status update.
Format the answer as a one-page briefing with bullets, risks, and next actions.Specify whether the output should sound official, executive-ready, plain-language, or employee-friendly.
Use a professional, neutral, public-sector tone suitable for a US agency audience.For government, HR, finance, healthcare, legal, and compliance workflows, accuracy guardrails matter more than clever wording.
Use only the facts below, flag assumptions, and include a section for items that need verification.Ask the model to surface uncertainty so the user can verify sensitive or official information before using it.
Before finalizing, list compliance risks, missing details, and any claims that need human review.Tested on this prompt category as of mid-2026. Ratings reflect quality for AI Prompts for System Design specifically.
| Model | Best for | Rating |
|---|---|---|
| ChatGPT (GPT-4o / GPT-5) | Everyday drafting and summaries | |
| Claude Sonnet 4.5 | Long documents and policy | |
| Gemini 2.5 Pro | Grounded in Google workspace | |
| Copilot (M365) | Office 365 integration | |
| Perplexity | Answers with citations |
Ratings reflect suitability for this category. Free tiers available on all listed models. Last tested May 2026 by PromptSpace editors.
Give the AI the input variables — DAU, requests per user per day, average payload size, retention window, replication factor — and ask it to show the intermediate arithmetic, not just the final QPS or TB number. If the output skips steps, push back with "show me the math." That is exactly what a design review will ask for.
No. AI can produce a plausible design and stress-test yours by generating failure modes and trade-offs you missed, but it does not own the on-call rotation, know your team's velocity, or feel the pain of a 3 AM page. Use AI to widen the option space and challenge assumptions; keep the decision with an accountable human.
1–2 pages. Any longer and no one reads it in three years. Cover context, 3–4 options with a real comparison (not "Option A: good; Option B: bad"), the decision, and consequences including what breaks if the decision turns out wrong. Store ADRs in the repo under `docs/adr/` and number them sequentially.
Neither answer is always right — the point of a system design interview is to justify the choice against the specific workload. AI-generated designs that hedge ("it depends") lose points. Pick a side, name the top 2 reasons, and acknowledge the trade-off you accepted. That is what senior signals look like.
Check your firm's AI policy. Public ChatGPT is usually off-limits for proprietary architecture; enterprise AI with a no-training data-processing agreement is generally fine. When in doubt, abstract — use generic entity names ("service A depends on service B") instead of real internal system names.
Learn the basics of creating stunning AI-generated images using prompts from our library.
GuideDiscover the secrets to crafting prompts that produce consistent, high-quality results.
CollectionCopy-paste 100 tested Midjourney v6 prompts: portraits, cinematic, fantasy, product shots & more. Free, updated for 2026 - instant results.
Social MediaCreate scroll-stopping Instagram content with these AI image prompts designed for Reels, Stories, and posts.
Browse our full library of ai prompts for system design — all free, copy-paste ready, no signup.
Or use our AI Prompt Generator to create custom prompts for your exact style in seconds.
Feed the AI the concrete constraints: expected QPS at launch and at 12-month growth, read/write ratio, average and 99th-percentile payload size, retention requirements, latency budget per endpoint, and consistency needs (strong, read-your-writes, eventual). Vague inputs — 'design a feed at scale' — produce vague outputs. Concrete inputs — '50M DAU, 200 posts/day/user, 90/10 read/write, p99 < 200ms' — produce numbers you can actually defend.
Then ask for the design in the standard four-part shape: (1) capacity estimation, (2) API design with request/response shapes, (3) data model with primary keys and indexes, and (4) failure modes with mitigations. Every prompt below is written to force that structure. When the AI hand-waves, push back with 'give me the actual math' or 'pick one and justify it.'
A good system design prompt names the workload shape (read-heavy, write-heavy, bursty, steady), the consistency requirement, and the acceptable failure mode when the primary dependency is degraded. Without those anchors the AI defaults to 'add a cache, add a queue, add a load balancer' — technically true, uselessly generic. With them, the AI has to reason about whether Redis is a look-aside cache or a source of truth, whether the queue is at-least-once or exactly-once, and what happens when the LB health check flaps.
Also state the team's operational reality: on-call rotation size, deployment cadence, whether multi-region is required at launch, and the budget ceiling. A design that assumes 50 engineers and unlimited AWS spend is not a design; it's a fantasy. The AI can produce a right-sized design if you tell it who is going to run it.
Capacity estimation is where senior engineers separate themselves from mid-levels in system design interviews and in real design reviews. The template below produces the standard set: QPS from DAU × requests-per-user-per-day / 86,400, storage from records × row-size × retention × replication factor, bandwidth from QPS × payload × overhead, and cache footprint from working set × hit-rate assumption.
Round aggressively and show the arithmetic. 'About 30K QPS steady, 100K QPS peak, so size for 150K QPS' is a defensible number. 'Some traffic' is not. The AI can produce these estimates cleanly if you ask for the intermediate math, not just the final number.
An Architecture Decision Record (ADR) is a 1–2 page document capturing a single non-trivial design decision: context, options considered, decision, and consequences. The ADR template below produces exactly that shape and forces the AI to write down the losing options along with the winner — which is where 90% of the value lives, because 'why did we pick Postgres over DynamoDB in 2024?' is a question you will absolutely be asked in 2027.
Pair ADRs with a lightweight observability plan (structured logs, RED/USE metrics, distributed traces, and 2–3 SLOs per service) and a written DR plan with RTO and RPO targets. These three artifacts — ADR, observability plan, DR plan — are the design deliverables that survive team turnover. AI drafts them in minutes; ownership and review keep them true.
Give the AI the input variables — DAU, requests per user per day, average payload size, retention window, replication factor — and ask it to show the intermediate arithmetic, not just the final QPS or TB number. If the output skips steps, push back with "show me the math." That is exactly what a design review will ask for.
No. AI can produce a plausible design and stress-test yours by generating failure modes and trade-offs you missed, but it does not own the on-call rotation, know your team's velocity, or feel the pain of a 3 AM page. Use AI to widen the option space and challenge assumptions; keep the decision with an accountable human.
1–2 pages. Any longer and no one reads it in three years. Cover context, 3–4 options with a real comparison (not "Option A: good; Option B: bad"), the decision, and consequences including what breaks if the decision turns out wrong. Store ADRs in the repo under `docs/adr/` and number them sequentially.
Neither answer is always right — the point of a system design interview is to justify the choice against the specific workload. AI-generated designs that hedge ("it depends") lose points. Pick a side, name the top 2 reasons, and acknowledge the trade-off you accepted. That is what senior signals look like.
Check your firm's AI policy. Public ChatGPT is usually off-limits for proprietary architecture; enterprise AI with a no-training data-processing agreement is generally fine. When in doubt, abstract — use generic entity names ("service A depends on service B") instead of real internal system names.