System design interview guide
How to Prepare for a System Design Interview
Use a repeatable process to turn an ambiguous product prompt into a concrete architecture—and explain why each decision belongs there.
What the interviewer is actually evaluating
A system design interview is not a memory test for one perfect architecture. The interviewer wants to see whether you can reduce ambiguity, identify the constraints that matter, construct a coherent request flow, and communicate the cost of your choices. Your diagram is evidence of your reasoning—not the final goal.
A seven-step system design interview framework
Clarify the product and scope
Start by identifying the users, the core actions, and what is explicitly out of scope. A strong candidate does not design every possible feature. They narrow an ambiguous prompt into a system that can be discussed within the interview.
Turn requirements into measurable constraints
Write down the functional requirements, then name the non-functional priorities: latency, availability, durability, consistency, throughput, security, or cost. The architecture should follow these priorities rather than a memorized diagram.
Estimate only what changes a decision
Use rough reads per second, writes per second, storage growth, payload size, and peak traffic when they affect the design. Back-of-the-envelope estimation is useful when it explains why you need caching, partitioning, asynchronous processing, or a CDN.
Define the API and data model
Before drawing infrastructure, make the main operations and stored entities concrete. APIs reveal the request paths; the data model reveals ownership, access patterns, indexes, and consistency boundaries.
Draw the simplest complete request flow
Connect the client to the edge or gateway, application services, storage, and any asynchronous workers. Explain one important read path and one important write path end to end before adding advanced components.
Deep-dive into the hardest constraint
Choose the part that makes this problem distinctive: feed fan-out, ordering, hot keys, geospatial lookup, distributed locking, media delivery, or exactly-once financial effects. This is where senior-level judgment becomes visible.
Test failures and defend trade-offs
Ask what happens when a database, region, queue, cache, or dependency is unavailable. Finish by stating the trade-offs you accepted, what you would monitor, and what you would change at the next order of magnitude.
A practical 60-minute interview plan
| Time | Focus | Output |
|---|---|---|
| 0–8 min | Clarify scope and requirements | Agreed problem boundary |
| 8–15 min | Estimate scale; define API and data | Constraints and access patterns |
| 15–30 min | Build the high-level design | Complete read/write flow |
| 30–48 min | Deep-dive into the hardest area | Defensible technical decisions |
| 48–60 min | Failures, trade-offs, and summary | Risks and next steps |
Common mistakes that weaken an answer
- ×Drawing components before agreeing on requirements.
- ×Adding queues, caches, and microservices without explaining why.
- ×Naming technologies instead of describing the request and data flow.
- ×Ignoring hot keys, retries, idempotency, and partial failures.
- ×Optimizing every dimension instead of prioritizing the stated constraints.
- ×Finishing the diagram without summarizing trade-offs and limitations.
Practise across different problem families
Do not repeat only one familiar diagram. Each problem family should force a different architectural decision.
URL Shortener
Read-heavy caching and durable mappings
Rate Limiter
Distributed counters and hot-path latency
Notification System
Async fan-out and real-time delivery
Chat System
Ordering, presence, and delivery guarantees
News Feed
Fan-out, ranking, and celebrity traffic
Ticket Booking
Concurrency, inventory, and double booking
System design interview FAQ
How long should a system design interview answer take?
Most full system design rounds last 45 to 60 minutes. Spend the opening minutes clarifying scope, then establish requirements and scale before drawing the architecture. Reserve time for a deep dive, failures, and trade-offs.
Do I need to calculate exact capacity numbers?
No. Use round numbers and state assumptions. Estimate only when the result changes an architectural decision, such as storage choice, caching, partitioning, bandwidth, or asynchronous processing.
Is there one correct system design answer?
Usually not. Interviewers evaluate whether your architecture follows the stated requirements and whether you can explain its limitations. A simpler design with clear trade-offs is stronger than a complicated diagram you cannot defend.
What is the best way to practise system design?
Use a repeatable process on several different problem families. Build the architecture yourself, explain the request flow out loud, review the missing decisions, and then repeat the same scenario before moving on.
Turn the framework into practice
Start with a real prompt, connect the architecture yourself, and use structured feedback to find the decisions you missed.
Start the free URL Shortener scenario →