codingsystem design

System Design Interview Answer

Structures a system design answer with requirements, architecture, database, APIs, scaling, and trade-offs.

Prompt

You are a staff engineer preparing for a system design interview. Design a system for [system description, e.g. 'a URL shortener like bit.ly' or 'a real-time chat application']. Follow this structure: (1) Requirements Clarification: list 5 functional requirements and 5 non-functional requirements (throughput, latency, availability targets with specific numbers), (2) Back-of-the-Envelope Estimation: calculate storage, bandwidth, and QPS for 5 years assuming [X] daily active users, (3) High-Level Architecture: describe 3-5 core components and how they interact (API gateway, application servers, database, cache, message queue, CDN), (4) Database Design: schema for key entities with choice of SQL vs NoSQL justified, (5) API Design: 3-5 core endpoints with request/response format, (6) Detailed Component Design: deep dive into the 2 most complex components, (7) Scaling: how to handle 10x and 100x growth (horizontal scaling, sharding strategy, caching layer), (8) Trade-offs: 2-3 design decisions you made and what you'd do differently with different constraints. Use ASCII diagrams for architecture.

Why this prompt works

The constraints score is 0 because system design is by nature an open-ended exercise: any constraint set you imposed in advance would limit the kind of trade-off discussion the prompt is meant to produce. Despite that low score, the prompt produces strong output because the eight-step structure (requirements clarification, estimation, architecture, database, API, deep dive, scaling, trade-offs) is the format every senior engineer interviewer expects you to follow. The 5-functional / 5-non-functional split forces the model to think about throughput, latency, and availability targets explicitly, which is where most candidates fall short under pressure. The trade-offs section at the end is what distinguishes good answers from textbook answers.

When to reach for it

You're prepping for senior engineering interviews and want worked examples showing the interview's actual structure.
You're studying system design and want a worked example for a system you've never thought through before.
You're a tech lead writing an architecture proposal and want a reference structure to follow.
You're an interviewer building question sets and want example answers to calibrate against.

How to customise it

The system description is everything. Be specific. 'Design Twitter' is too broad; 'design a notification fan-out system that supports 10K notifications/sec to 100M users' produces a sharp answer. The estimation step's accuracy depends on the user count input; pick a real number rather than a placeholder. For interviews specifically, ask the model to add 'common follow-up questions an interviewer might ask' at the end; the standard template doesn't include this but it's how interviews actually go.

What good output looks like

An eight-section answer: requirements (5 functional, 5 non-functional), back-of-envelope estimation (storage, bandwidth, QPS), high-level architecture with ASCII diagram, database design with SQL/NoSQL choice, API design (3 to 5 endpoints), deep dive on 2 components, scaling plan for 10x and 100x, trade-offs section. Total length around 2,500 to 4,000 words. The deep-dive section is where the answer lives or dies; if it feels light, ask for more depth on one component rather than another deep-dive.

Watch out for

The model can produce confident estimation numbers (storage, bandwidth, QPS) that don't quite hold up to scrutiny. Re-do the math yourself for any answer you'll present in an interview; you'll be expected to defend the numbers under questioning. The trade-offs section is the most reliable output; the deep-dive components vary in quality depending on whether the system is well-known (Twitter, Uber) or niche (a payments ledger, a real-time bidding system).

system designinterviewarchitecturescalingdistributed systemsChatGPT / Claude