System design interviews feel scary because there is no single right answer. “Design a URL shortener” or “Design a chat app” can go in a hundred directions. The good news: interviewers are not looking for a perfect design. They want to see how you think, how you handle trade-offs, and whether you can lead a technical conversation.
A simple framework keeps you on track.
Step 1: Clarify the requirements (5 minutes)
Never start drawing right away. Ask questions first:
- Who uses it, and how many? Thousands of users and hundreds of millions are very different problems.
- What are the core features? Pick the two or three that matter most and say what you will leave out.
- What matters most? Speed, consistency, cost, or availability.
Write the answers down where the interviewer can see them. This becomes your checklist.
Step 2: Estimate the scale (3 minutes)
Rough numbers guide every later decision. Estimate:
- Requests per second for reads and for writes.
- How much data you store per day and per year.
- Whether the system is read-heavy or write-heavy.
You do not need exact math. Being within a factor of ten is enough to choose the right tools.
Step 3: Sketch the high-level design (10 minutes)
Draw the main parts and how a request flows through them:
- Clients (web, mobile).
- Load balancer to spread traffic.
- Application servers with the core logic.
- Database for the main data.
- Cache for data that is read often.
- Queue for work that can happen later, like sending emails.
Walk the interviewer through one request from start to finish. This proves the design actually works.
Step 4: Go deep on one or two parts (15 minutes)
The interviewer will usually push on the hardest part. Common deep dives:
- Database choice: SQL for structured data and transactions, NoSQL for huge scale and flexible data.
- Scaling the database: replication for more reads, sharding for more writes.
- Caching: what to cache, for how long, and what happens when cached data goes stale.
- Handling failure: what happens if a server or a whole data center goes down.
Pick the part that matters most for this specific system, and say why you picked it.
Step 5: Discuss trade-offs (5 minutes)
End by naming what you gave up. Every design choice has a cost:
- “I chose eventual consistency here, so a user might see an old message for a second, but the system stays fast and available.”
- “Sharding by user ID makes most queries simple, but cross-user reports get harder.”
This is often what separates a good answer from a great one.
Practice questions to start with
- Design a URL shortener.
- Design a rate limiter.
- Design a news feed.
- Design a chat application.
- Design a file storage service.
Run each one through the five steps out loud, with a timer.
How InterviewStorm helps
During a system design round, InterviewStorm gives you a structure to talk through as the question is asked: requirements to clarify, components to sketch, where the design will break first, and trade-offs worth naming. It is a strong practice partner too. See system design help.
For the rest of the loop, read our guides on coding interviews and the STAR method.