ChatGPT for System Design: The Prompts That Actually Move the Conversation Forward

I've been writing code for about twelve years, and the hardest part of system design has never been the code itself. It's the thinking — sitting with a whiteboard or a blank doc, trying to stress-test an architecture before you've built anything. You're basically arguing with yourself, and you're bad at it because you already believe your design is good.

ChatGPT changed how I approach this. Not because it generates designs for me — it doesn't. The outputs are usually too generic to be directly useful. What it does well is play the skeptic. It asks the questions I forgot to ask myself.

Here's how I actually use it.

Capacity Estimation Without the Guesswork

Back-of-envelope math is one of those things senior engineers make look easy. In reality, most of us are roughing it. If I'm designing a notification service that needs to handle peak traffic during a big product event, I need rough numbers before I can make any architectural decisions.

Prompt: "I need to estimate capacity for a real-time notification service. Assume 2 million daily active users, 15% of them active during peak hour, each user triggering an average of 3 notifications per session. Walk me through the back-of-envelope math for requests per second at peak, estimated message queue depth, and storage requirements if we retain notifications for 30 days. Point out where my assumptions are weakest."

What I get back isn't gospel — I always sanity check the math — but it gets me to an answer in 3 minutes instead of 30. More importantly, it surfaces the assumptions I'm making implicitly (like "30-day retention" — is that right for my use case?).

Trade-Off Analysis, Not Architecture Recommendations

Every experienced engineer has an opinion on SQL vs. NoSQL. ChatGPT has all of those opinions baked in, and it'll argue any side. The trick is forcing it to make the argument conditional on your constraints.

Prompt: "I'm building a product catalog for an e-commerce platform. I'm deciding between PostgreSQL and DynamoDB. My constraints: ~5 million SKUs, read-heavy workload (95% reads), product data has variable attributes per category, and we need full-text search. Give me the honest trade-offs — not general ones, specific to these constraints. Which choice creates more long-term pain?"

The "which creates more long-term pain" framing matters. It stops ChatGPT from hedging with "it depends on your use case" and forces it to make a call you can argue with.

Finding Failure Modes Before They Find You

This is where ChatGPT earns its keep. I'm not good at imagining what I haven't built yet failing. Humans are bad at this in general — we design for the happy path and add error handling when things actually break.

Prompt: "I'm designing a system that needs to process financial transactions between a mobile app and a third-party payment processor. Here's my current approach: the app calls our Node.js API, which calls the payment processor synchronously, writes the result to Postgres, then emits a webhook to the client. Walk me through the top 3 failure modes in this design and what would need to change to handle 10x the current load."

I've run this on five different designs and every single time it surfaces something I missed. Idempotency on retries, what happens if the database write succeeds but the webhook fails, synchronous payment processor calls creating latency spikes under load — real problems that cost real money to fix in production.

Identifying Hidden Coupling

This is the sneakiest kind of architectural debt. Services that look decoupled aren't. You deploy one and something else breaks. ChatGPT is surprisingly good at reading a design description and pointing to where the coupling lives.

Prompt: "Here's my microservices architecture: [describe your services and how they communicate]. I think these services are loosely coupled, but I'm worried I'm missing something. Identify any hidden coupling — shared state, synchronous dependencies, or implicit contracts — that would make independent deployments risky."

Interview Prep That Actually Prepares You

System design interviews aren't just about knowing architecture patterns. They're about communicating under pressure while someone challenges your reasoning. ChatGPT is a patient interviewer who will play devil's advocate on demand.

Prompt: "I'm preparing for a system design interview. Act as the interviewer. Give me the prompt 'Design a URL shortener that can handle 100 million URLs and 10 billion redirects per month.' Ask me clarifying questions first, then challenge my design choices as I explain them. Be tough but fair — if my reasoning is sound, accept it. If it isn't, push back."

The key is asking it to push back only when your reasoning is actually weak. Otherwise it'll argue with everything, which isn't useful.

The Mindset Shift

The mistake most developers make is treating ChatGPT like a design generator. They describe a problem and ask "what's the best architecture?" and get back a generic blog post answer.

Treat it like a senior engineer who knows a lot but doesn't know your specific constraints. Your job is to give it the context it needs to ask the right questions. The prompts above all share a structure: they give constraints, describe a specific design, and ask for targeted criticism rather than open-ended recommendations.

The design is still yours. ChatGPT just makes the thinking faster and the blind spots smaller.

If you want more prompts structured this way — covering code review, debugging, and architectural decision records — I've put together a pack of 200 developer-focused prompts that I use in my own workflow.

Get 200 ChatGPT Prompts for Developers — $19 instant download