How should I structure a system design interview answer?

Structure a system design interview answer in this order: clarify requirements, define non-functional goals, estimate scale, design APIs, model data, draw the high-level architecture, deep dive into the hardest component, and close with bottlenecks and trade-offs. This order keeps your answer understandable and makes every design choice trace back to a requirement.

If you only remember one thing, remember this: architecture should follow scope. Do not design before you know what problem you are solving.

Use the same skeleton for almost every backend system design prompt:

1. Clarify the product. What are users trying to do? Which features are in scope?
2. Write functional requirements. These are the actions the system must support.
3. Write non-functional requirements. These are quality goals: latency, availability, consistency, durability, throughput, privacy, and cost.
4. Estimate capacity. Use rough numbers for QPS, storage, bandwidth, and read/write ratio. The size calculation guide is the foundation here.
5. Define APIs. Show the main client or service calls.
6. Model data. Identify the core entities and access patterns.
7. Draw the high-level design. Include clients, gateways, services, caches, databases, queues, and external dependencies.
8. Deep dive. Spend time on the component that carries the most risk.
9. Discuss trade-offs. Explain what you chose and what you gave up.

This is the same flow used in System Design Structure, with more emphasis on interview pacing.

Suppose the prompt is Design a URL Shortener.

Start with scope: users create short links and anyone can redirect through them. Ask whether custom aliases, expiration, analytics, and abuse prevention are required.

Then define non-functional requirements: redirects should be low latency and highly available; link creation can tolerate slightly higher latency; mapping correctness matters.

Estimate scale: if there are 100 million redirects per day, that is roughly 1,200 redirects per second on average, with higher peak traffic. Storage is mostly URL mappings and click events.

APIs are simple:

• POST /links to create a short URL
• GET /{shortKey} to redirect

The high-level design can use an API gateway, link creation service, redirect service, primary database, cache, and async analytics pipeline. For deeper design, explain short key generation and cache strategy. If a link becomes hot, cache it aggressively. If analytics writes are heavy, push click events to a queue.

Notice the order. You did not begin with Redis. Redis appeared because redirect latency and hot-link traffic required it.

Starting with a diagram. A diagram before requirements is usually a guess.

Skipping APIs and data model. Interviewers need to see how the system is used and what state exists.

Treating every section equally. You do not have time. Spend less time on obvious parts and more time on the risk: ranking for autocomplete, fan-out for chat, transcoding for video, consistency for payments.

Forgetting the read path and write path. Many systems have very different pressure on reads and writes. Databases & Caching helps explain why.

Ending without trade-offs. The final minutes should show judgment. Mention consistency from CAP Theorem, partitioning from Sharding, or service boundaries from Microservices when relevant.

Practice the framework on:

• URL Shortener for a read-heavy service
• Notification System for async fan-out
• Payment System for correctness and auditability
• YouTube for storage, processing, and CDN delivery

After each attempt, ask: did every component in my diagram come from a requirement or estimate? If not, remove it or justify it.

A good system design answer is not a list of technologies. It is a chain of reasoning: requirements create constraints, constraints create architecture, and architecture creates trade-offs.