How to Structure a 45-Minute System Design Interview
Most system design interviews are not lost on knowledge. They are lost on time: twenty minutes on requirements, a beautiful diagram, and no time left for the one deep dive the interviewer cared about.
A fixed structure fixes that. Here is one that fits a 45-minute slot, with what to say in each part and the traps to avoid.
The shape of the interview
| Minutes | Phase | Output |
|---|---|---|
| 0–5 | Requirements | 3–5 functional requirements, 2–3 non-functional ones, explicit out-of-scope list |
| 5–8 | Estimates | Requests per second, storage per year, read/write ratio |
| 8–12 | API and data model | Core endpoints, main entities and their keys |
| 12–25 | High-level design | Boxes and arrows that satisfy every functional requirement |
| 25–40 | Deep dives | One or two components taken to production depth |
| 40–45 | Wrap-up | Bottlenecks, failure modes, what you'd do next |
The numbers are a guide, not a rule. The point is to know where you are and move on deliberately.
1. Requirements (0–5 min)
Ask questions that change the design, not questions that fill time.
- Functional: what must the system do? Write three to five as short verbs: "post a message", "see the latest 50 messages", "get notified when mentioned".
- Non-functional: scale, latency, availability, consistency. "Is it fine if a like count is a few seconds stale?" is a question that changes your design. "What language should I use?" is not.
- Out of scope: say it out loud. "I'll leave out search and admin tools unless you want them."
Trap: asking twenty questions. Ask the five that matter, state reasonable assumptions for the rest, and invite correction.
2. Estimates (5–8 min)
You need orders of magnitude, not precision. A day has 86,400 seconds; round it to 100,000 and the maths gets easy:
- 10 million requests per day ≈ 100 requests per second on average.
- Assume peak is 2–3x the average unless told otherwise.
- Storage: items per day × size × 365 × years of retention.
Then say what the number means: "About 300 writes per second at peak. One well-indexed database handles that; reads are the real load."
3. API and data model (8–12 min)
Write the three or four calls the client actually makes, with their key parameters:
POST /messages { channelId, text } -> { messageId, createdAt }
GET /channels/{id}/messages?before=<cursor>&limit=50Then the main entities and how you look them up. The access pattern ("latest 50 messages in a channel") decides the key ("channelId plus time-ordered messageId"), not the other way round.
4. High-level design (12–25 min)
Draw the simplest design that satisfies every functional requirement: clients, a load balancer, stateless services, a database, maybe a cache and a queue. Walk one request end to end.
- Name the reason for every box. "A queue here so a slow notification service can't slow down sending."
- Don't add components to look senior. Each one needs a job you can state.
Trap: redrawing. Get a correct, boring design first. Improve it in the deep dives.
5. Deep dives (25–40 min)
This is where seniority shows. Pick the one or two hardest parts, or ask the interviewer which they care about. Typical candidates:
- Hot keys: one celebrity post getting 50,000 likes a minute. Sharded counters, or buffering increments and aggregating.
- Fan-out: push to followers on write, or pull on read? Usually a hybrid, with high-follower accounts handled differently.
- Consistency: what can be eventually consistent (counts, feeds) and what can't (payments, inventory).
- Failure: what happens when the cache is down, the queue backs up, or a region fails.
For each, state the trade-off, not just the choice: "Sharding the counter removes the hotspot, but reads now sum N rows. That's fine because reads are cached."
6. Wrap-up (40–45 min)
Summarise the design in two sentences, name the biggest remaining risk, and say what you'd monitor. Interviewers remember the ending.
The five most common mistakes
- No numbers. Without estimates you can't justify a cache, sharding or a queue.
- Jumping to technology. "Kafka" is not a design. Say what the component must guarantee first.
- Ignoring the read path. Most systems are read-heavy; the write path is rarely where they break.
- Single points of failure left unmentioned.
- Never stating a trade-off. Every senior answer contains the words "the cost is".
Practise the phases separately. Prepd breaks each system design question into steps like these and gives written feedback on every answer, so you can drill the part you're weakest at. The first three drills below are free and need no sign-up.