A system design interview is not a quiz with one right answer. It is a 45–60 minute simulation of a design review: you are handed a vague product ("design Instagram"), and the interviewer watches how you turn ambiguity into a system that works, then how you reason about where it breaks. Two candidates can draw the same boxes and get opposite verdicts, because what is scored is the path: which questions you asked, which numbers justified a choice, and whether you can name the trade-off you just made.
Every case study in this section is written in the same eight steps, in this order. After a few of them the order becomes habit, and habit is what keeps you calm with a whiteboard and a clock.
It's like planning a house with a client. First you ask what they need (rooms, budget, who lives there), then sketch the floor plan, then detail the wiring and plumbing, and finally answer "what if we add a floor later?" Skipping straight to the wiring is how you build the wrong house.
45-minute interview (scale proportionally for 60)
0-2 1. Problem statement restate the product in one or two sentences
2-5 2. Functional reqs 3-5 features in scope; say what is out of scope
5-9 3. Non-functional reqs scale (DAU, QPS, storage), latency, availability,
consistency, durability; quick estimates
9-12 4. Core entities the nouns: User, Post, Follow, Message ...
12-15 5. API the 3-5 endpoints the features need
15-27 6. HLD (high level) boxes and arrows for the happy path, end to end
27-40 7. LLD (low level) schemas + keys, the key algorithm, the hard
component's internals, hot spots, failure
40-45 8. Follow-up questions interviewer's "what if": 10x scale, a region
down, a celebrity user ... answer with trade-offsThe budget exists because the most common failure is running out of time before the LLD, which is where senior signal lives. Steps 1–5 should feel brisk: enough to anchor decisions, not a spreadsheet. If the interviewer pulls you into a detail early, go with it; this is a default order, not a script.
Problem statement. One or two sentences in your own words: "A service that turns long URLs into short ones and redirects anyone who opens the short one." It proves you understood the product and gives both of you a shared anchor.
Functional requirements are the features: "users can post a photo", "followers see it in their feed". Pick three to five and say explicitly what you are leaving out ("no comments or DMs for now"). Scoping out is a skill, not an admission.
Non-functional requirements are what actually shape the architecture:
Core entities are the nouns the system stores and moves: for a news feed, User, Post, Follow, FeedItem. Listing them before the API keeps the API honest, and each entity later becomes a table, a collection or a cache key in the LLD. Note the relationships (a User has many Posts; Follow is a many-to-many edge) and the access pattern for each: "fetch the latest 20 feed items for a user" matters more than every column.
API: the handful of endpoints the functional requirements need, with the important parameters and what they return.
POST /v1/posts { text, media_ids[] } -> { post_id }
GET /v1/feed?cursor=<c>&limit=20 -> { items[], next_cursor }
POST /v1/users/{id}/follow -> 204
Things worth saying out loud:
- cursor-based pagination (not offset) for feeds that change underneath you
- an Idempotency-Key header on writes that must not double-apply
- auth via a token; the user id comes from the token, not the bodyHLD (high-level design) is the system as boxes and arrows: clients, load balancer, the services, the data stores, caches, queues, CDN, and which calls are synchronous vs asynchronous. Draw the happy path for each functional requirement end to end, and attach a reason to each box:
Weak: "Then we add a cache."
Strong: "Reads are ~100x writes and the hot set is small (the top 20% of
links get ~80% of clicks), so a Redis cache in front of the DB
absorbs most reads. Cache-aside, TTL 24h; a few seconds of
staleness after an edit is fine because links rarely change."LLD (low-level design) zooms into the parts that decide whether the HLD actually works:
The last minutes are the interviewer probing: "what if traffic grows 10x?", "what if this celebrity has 50M followers?", "what if the cache cluster goes down?". Good answers name the bottleneck, the change, and its cost. Useful prompts to have ready: