How to approach a design interview
In one line
A design interview rewards a clear, structured conversation: pin down requirements, size the problem, sketch a simple design, then go deep on the hardest parts and their trade-offs.
What it is
A system design interview is a 45 to 60 minute open-ended conversation where you design a large system, such as a URL shortener, a news feed or a chat app. There is no single correct answer. The interviewer watches how you reason, not whether you reproduce a famous architecture.
Most strong candidates follow the same framework: clarify requirements, estimate scale, define the API, choose a data model, draw a high-level design, deep-dive into one or two hard components, then discuss bottlenecks, failures and trade-offs. The framework keeps you from jumping into details too early or running out of time before the interesting part.
Why interviewers ask
Senior and mid-level loops almost always include a design round, and it often decides the level you are hired at. Interviewers test whether you can turn a vague problem into concrete requirements, make reasonable numeric estimates, pick sensible building blocks, and explain trade-offs out loud the way you would with teammates.
How it works
- 1Clarify requirements (about 5 minutes): list functional requirements (what users can do) and non-functional ones (scale, latency, availability, consistency). Agree on what is out of scope, for example 'no analytics dashboard'.
- 2Estimate scale (about 5 minutes): daily active users, requests per second for reads and writes, storage per year, bandwidth. Round aggressively; one day is about 100,000 seconds (86,400 exactly). The numbers tell you whether you need one database or a sharded fleet.
- 3Define the API (about 5 minutes): a few endpoints with inputs and outputs, for example POST /messages and GET /conversations/{id}/messages?before=cursor. This fixes the contract before the internals.
- 4Choose a data model: the main entities, their key fields, and the access patterns. Access patterns decide SQL vs NoSQL and the primary or partition key.
- 5Draw the high-level design (about 10 minutes): clients, load balancer, stateless services, databases, caches, queues, CDN. Walk one read and one write request through the diagram.
- 6Deep-dive (about 15 minutes): pick the one or two hardest parts, usually the ones the interviewer nudges toward, and go deep: key generation, fan-out, sharding scheme, delivery guarantees.
- 7Bottlenecks and wrap-up (about 5 minutes): name single points of failure, hot spots and what breaks at 10x load, then how you would monitor and evolve the system.
Worked example · The first ten minutes of 'Design Instagram'
- Requirements: users upload photos, follow others, and see a feed of followed users' photos. Non-functional: feed loads in under 200 ms, uploads must never be lost, a few seconds of feed delay is fine (eventual consistency). Out of scope: stories, direct messages, ads.
- Estimates: 500M daily users, each views the feed 10 times a day = 5B feed reads a day, about 58,000 per second on average (5B / 86,400), maybe 150,000 at peak. Uploads: 100M photos a day, about 1,200 per second.
- Storage: 100M photos x 2 MB = 200 TB of new photos per day, so photos go to object storage (like S3) behind a CDN, never in the database.
- Conclusion from the numbers: reads outnumber writes about 50 to 1, so the design should precompute feeds and cache aggressively. That one sentence sets up the whole deep-dive on feed fan-out.
Picture it
It is like an architect meeting a client. A good architect does not start drawing walls; they ask how many people will live there, the budget and what matters most, sketch a floor plan, and only then detail the plumbing in the tricky rooms.
Key patterns
Let numbers drive the design
When: Right after requirements
How: Compute reads per second, writes per second and storage. A read-heavy system suggests caches and replicas; a write-heavy one suggests queues, sharding and append-friendly stores.
Start simple, then scale
When: Drawing the first diagram
How: Begin with client, one service and one database that would work for 1,000 users, then add load balancers, caches, replicas and shards only where the estimates demand them.
Follow the request
When: Explaining the high-level design
How: Trace one write and one read end to end through every box, naming the data that moves. This exposes missing pieces quickly.
State the trade-off explicitly
When: Every major choice
How: Say what you chose, what you gave up and when you would choose differently, for example 'NoSQL for write throughput, giving up joins, which we do not need here'.
Real-world use
News feed (Twitter/X, Instagram)
A classic prompt that tests fan-out on write vs fan-out on read. Twitter has described precomputing home timelines in Redis for most users while handling accounts with millions of followers differently.
Ride hailing (Uber)
Tests geospatial indexing and real-time location updates. Uber built and open-sourced H3, a hexagonal grid system, to bucket locations for matching riders and drivers.
Video streaming (YouTube, Netflix)
Tests blob storage, transcoding pipelines and CDNs. Netflix serves most video from its own Open Connect CDN appliances placed inside internet providers' networks.
Collaborative editing (Google Docs)
Tests real-time sync and conflict resolution, usually discussed through operational transformation or CRDTs.
In a project
You are preparing for a senior backend loop and want to practise turning a vague prompt, 'design a food delivery app', into a complete 45-minute answer.
- Write a one-page template with the seven stages and rough time boxes, and use it for every practice prompt.
- For the food delivery prompt, agree on core features (browse restaurants, place order, track courier) and that payments are handled by a third party.
- Estimate: 10M orders a day is about 115 orders per second, while courier location pings every 5 seconds from 500,000 couriers are 100,000 writes per second, so location tracking is the real scaling problem.
- Sketch services (orders, restaurants, courier location, notifications) with a relational database for orders and an in-memory geo index for courier positions.
- Deep-dive on courier location ingestion and matching, then close with failure modes (payment provider down, courier app offline).
Impact: After a few timed rehearsals you finish every stage within 45 minutes, your estimates point you to the true bottleneck instead of a guess, and interviewers see a calm, structured conversation rather than a jumble of boxes.
Trade-offs
Use it when
- Any open-ended design prompt, including product design and API design rounds
- Real design reviews at work: the same steps make a good design document
Avoid it when
- Following the template rigidly when the interviewer clearly wants to jump to a specific deep-dive; adapt and follow their lead
- Spending 15 minutes on estimates; rough orders of magnitude are enough
Common mistakes
- Drawing boxes before asking a single question about requirements or scale.
- Naming technologies (Kafka, Cassandra) without saying what problem each one solves here.
- Designing for Google scale when the stated numbers fit on one database with a replica.
- Staying shallow everywhere instead of going deep on the hardest component.
- Never mentioning failures: what happens when a server, a database or a whole region goes down.
Interview questions
Quick revision
- Order: requirements, estimates, API, data model, high-level design, deep-dives, bottlenecks.
- Functional = what users do; non-functional = scale, latency, availability, consistency.
- 1 day is about 100,000 seconds; 1M requests a day is about 12 per second.
- Read-heavy: cache and replicate. Write-heavy: queue, shard, append-only stores.
- Trace one read and one write through the diagram.
- Every choice: what you chose, what you gave up, when you would switch.
- Finish with failure modes and monitoring.
Check yourself
1. What should you do first in a system design interview?
2. A service gets 8.64 million requests a day, spread evenly. Roughly how many requests per second is that?
3. Your estimates show reads outnumber writes 100 to 1. Which design direction does this suggest?
4. Which is a non-functional requirement?
Saved on this device. Create a free account to keep it on every device.
Practise this with Sam
A real mock interview, out loud, with an honest scorecard. Free to start.