On this page
Description
A system design interview hands you a one-line prompt - "Design Instagram" - and 45 minutes. There's no single right answer. What the interviewer is really watching is how you think: can you turn a vague request into clear requirements, size the problem, make choices that follow from the numbers, and say honestly what each choice costs?
The most common way to fail isn't a wrong box. It's the first two minutes. Hearing a familiar product, many candidates start drawing straight away: load balancer, microservices, Kafka, a cache. Twenty minutes later the interviewer asks "how many photos a day?" or "does the feed need to be real-time?", and the design turns out to answer a different question. Nothing on the board was tied to a requirement, so nothing can be defended.
A simple, repeatable structure fixes that. In this lesson:
- The six steps of a 45-minute round, and roughly how long each takes.
- Asking the right questions before you draw anything.
- Quick estimates, the API and the data model.
- A simple design first, then deep dives where it matters.
- Saying trade-offs out loud, and what interviewers actually score.
The six steps (for a 45-minute round)
| Step | Time | What you produce |
|---|---|---|
| 1. Requirements | ~5 min | Core features, qualities (latency, availability, consistency), scale, what's out of scope |
| 2. Estimation | ~5 min | Requests per second (average and peak), read:write ratio, storage, bandwidth |
| 3. API and data model | ~5 min | The main endpoints; the entities and how they're read |
| 4. High-level design | ~10 min | A simple design that works end to end |
| 5. Deep dives | ~15 min | Two or three components the requirements stress most |
| 6. Wrap-up | ~5 min | Bottlenecks, failure modes, what you'd do next |
The times flex - a 60-minute round gives the deep dives more room - but the order holds.
1. Requirements
Ask, don't assume. Three kinds of question:
- Functional: what must users be able to do? Pick the core - for Instagram: upload a photo, follow people, see a feed of followed accounts' photos. Say explicitly what you're leaving out ("no stories, DMs or search unless you want them").
- Non-functional: which qualities matter? Latency (a feed that loads in under 200 ms), availability (it should load even if some components fail), consistency (is it fine if a new photo appears a few seconds later? usually yes), durability (never lose an uploaded photo).
- Scale: how many users, how active, how much data? If the interviewer says "you decide", pick round numbers and write them down.
Write the list on the board. Every later decision points back to it.
2. Estimation
Rough numbers decide where the complexity goes. 500 million daily users each opening the feed 10 times is 5 billion reads a day - about 58,000 per second on average, perhaps 150,000 at peak. 100 million uploads a day is about 1,200 per second. Reads outnumber writes 50 to 1, so the read path gets the design effort. Keep it to one or two significant figures; precision to the digit wastes time and signals the wrong priority. (The next skill covers estimation properly.)
3. API and data model
A few endpoints make the design concrete:
POST /photos (multipart upload) -> { photoId }
POST /users/{id}/follow
GET /feed?cursor={opaque}&limit=20 -> { items[], nextCursor }
Note the cursor: a feed that grows while you scroll breaks offset pagination (?page=3 shows duplicates or skips when new items arrive). Then the data model - and more important than the fields, the access patterns: "the feed is read by user ID, newest first"; "a photo is read by its ID"; "followers are listed by followee ID". Access patterns decide the store, the indexes and the shard key.
4. High-level design
Draw the simplest thing that works end to end: clients → load balancer → stateless app servers → a database, plus object storage for the photo files. Walk one write and one read through it. Only then add what the numbers demand: a cache for the 50:1 read path, a CDN for photo bytes, a queue for the work that can lag (thumbnails, fan-out). Each addition gets one sentence of justification tied to a requirement.
For the photo app, after those additions, the board might look like this:
Every box should be able to answer "which requirement put you here?" - the CDN for photo bandwidth, the feed cache for the 50:1 read ratio and the 200 ms target, the queue because fan-out may lag by a few seconds.
5. Deep dives
Choose the two or three parts where the requirements push hardest - for a feed, how a new photo reaches followers' feeds (and what happens with an account that has 100 million followers), how the feed cache stays fresh, how the photo store survives a data-center loss. Go deep: the data structures, the failure modes, the trade-off you're making. Interviewers often steer here; follow them.
6. Wrap-up
Name the bottlenecks and failure modes that remain and what you'd do next with more time or 10x the traffic. This is where you show judgment: "the fan-out workers are the first thing to break at 10x; I'd shard the queue by user ID and move celebrity accounts to pull-based reads."
Trade-offs, out loud
The thread through every step: state the choice, the requirement it serves and what it costs. "I'll use a cache-aside Redis cluster for feeds because reads are 50x writes and must be under 200 ms; the cost is up to a minute of staleness, which the requirements allow." One sentence like that is worth more than three boxes without one.
What the interviewer is scoring
| Signal | Weak | Strong |
|---|---|---|
| Scoping | Starts drawing immediately | Asks about users, scale and the one or two qualities that matter, writes them down |
| Estimation | Skips it, or computes to the last digit | Rough numbers that change a decision ("50:1 reads, so the read path gets the effort") |
| Design | Many boxes, none justified | A simple working design, each addition tied to a requirement |
| Depth | Shallow on everything | Two or three deep dives where the requirements push |
| Trade-offs | "We'll use Kafka" | "A partitioned log, so fan-out can lag without blocking uploads; costs a few seconds of staleness" |
| Communication | Long silences | Narrates, checks in, follows the interviewer's steer |
Read more — when the interviewer is quiet
Some interviewers say almost nothing so you can show you can drive. Treat silence as "keep going": state your assumption, give a time check ("I've got the high-level design; I'd like to spend ten minutes on the feed path - sound good?") and proceed. A quick check-in every few minutes costs nothing and lets them redirect you before you spend fifteen minutes on the wrong component.
Common mistakes
- Designing before scoping. The design ends up answering questions nobody asked.
- Covering every feature shallowly. Twelve boxes with no depth scores worse than five boxes with two real deep dives.
- Name-dropping technology. "Kafka" isn't a design decision; "a partitioned log so fan-out can lag without blocking uploads" is.
- Going silent. The interviewer can only grade the reasoning you say out loud - narrate, and check in before long deep dives.
- Treating the first design as final. Say what breaks at 10x; it shows you know the design's limits.
Going further. The deep dive (next tab) covers what separates a senior from a staff-level answer, the availability arithmetic behind "four nines", SLOs and error budgets, how to run a deep dive, handling pushback, and talking about cost, operations and how a design evolves.
Check yourself
Try to answer before opening each one - recalling beats re-reading.
1. Fifteen minutes in, the interviewer says "assume 10x the users you estimated". What do you do?
Show answer
Redo the one or two numbers that change (requests per second, storage), then revisit the components those numbers stress - usually the read path and the data store's partitioning. Say what still holds and what changes, rather than starting over.
2. Why ask whether a new post must appear in followers' feeds immediately?
Show answer
Because it decides the consistency requirement, which decides the design. "Within a few seconds" allows asynchronous fan-out through a queue and cached feeds; "immediately, everywhere" forces synchronous work on the write path and costs latency and availability.
3. You have 15 minutes for deep dives and three candidates: the feed read path, the login flow and the photo storage. Which do you pick for a 50:1 read-heavy photo app?
Show answer
The feed read path first - it carries the load and the latency requirement - then photo storage (durability and bandwidth). Login is standard and rarely where the design is tested; mention it and move on.
Key takeaways
- Structure beats inspiration: requirements, estimate, API and data model, high-level design, deep dives, wrap-up.
- Pin down functional requirements, non-functional qualities and scale - and say what's out of scope.
- Rough numbers decide where complexity goes; one or two significant figures are enough.
- Access patterns ("read by user ID, newest first") decide storage, indexes and sharding.
- Get a simple end-to-end design on the board early, then go deep where the requirements push.
- Every choice gets a reason and a cost, said out loud.