System design interview guides
A system design interview tests whether you can turn a vague product prompt into a defensible architecture in about 45 minutes. These guides teach the method first, then the concepts every design leans on, then full walk-throughs you can practice out loud.
By Evin JohnPublished 4 min read
A 45-minute plan for any prompt
- Requirements (about 5 minutes)Ask what the product must do, for whom, and at what scale. Write functional and non-functional requirements separately and agree what is out of scope.
- Estimates (about 5 minutes)Requests a second, read/write ratio, storage over a few years, bandwidth. Round hard; the point is to find which resource is the bottleneck. See capacity estimation.
- API and data model (about 5 minutes)Name the two to five calls the product needs and the entities they touch. This anchors the rest of the discussion.
- High-level design (about 10 minutes)Clients, load balancer, services, storage, caches, queues. Walk one request end to end before adding anything clever.
- Deep dives (about 10 to 15 minutes)Go deep on the one or two parts that make this product hard: code generation for a URL shortener, fan-out for a feed, matching for ride-hailing.
- Trade-offs and failures (about 5 minutes)What breaks first as traffic grows, what happens when a component dies, and what you chose not to do and why.
The full version of this plan, with what to say at each stage, is in how to structure a system design interview.
What interviewers actually grade
| Signal | What it looks like in the room |
|---|---|
| Scoping | You ask about users, scale and features before drawing, and you write down what is out of scope. |
| Quantitative reasoning | Your choices follow from numbers you estimated, such as a cache sized from the hot set. |
| Trade-off awareness | For each major choice you name the alternative and what you gave up. |
| Depth on demand | When asked "how exactly?" you can go one level down: the schema, the partition key, the retry policy. |
| Communication | You narrate, check in with the interviewer and keep the diagram in step with what you say. |
The concepts behind every design
- CachingCache patterns, invalidation, stampedes, hot keys and sizing a cache.
- Capacity estimationQPS, storage, bandwidth and cache memory from round numbers, worked through.
- Consistency and CAPCAP stated precisely, PACELC, consistency models and quorum arithmetic.
- Interview frameworkThe 45-minute plan, what to say at each stage and what changes by level.
- ShardingShard keys, consistent hashing, hot partitions and resharding.
- SQL vs NoSQLPick a data model from access patterns, with a decision table and myths.
Full walk-throughs
Each walk-through follows the same order as the plan above, with estimates, an API, a data model, an architecture diagram, failure modes and the trade-offs worth raising.
- Collaborative editorOT or CRDTs, one session server per document, logs and snapshots.
- File storageBlocks, content hashes, a metadata database and conflict-safe sync.
- Job schedulerLeases, at-least-once runs, retries, missed runs and DST-safe cron.
- Notification systemFan-out queues, preferences, retries and duplicate-free delivery.
- Payment systemIdempotency keys, a double-entry ledger and reconciliation with the PSP.
- Rate limiterToken bucket vs sliding windows, atomic Redis checks, fail-open policy.
- Search autocompleteTop-k tries, an offline log pipeline and caching for 100 ms responses.
- URL shortenerCode generation, a cached redirect path and the 301 vs 302 trade-off.
Product-style prompts are covered too: design Uber (geospatial matching), design WhatsApp (real-time delivery), design Netflix (video streaming and CDNs) and design Twitter (timeline fan-out).
How to practice
- Talk, do not read. Pick a prompt, set a 45-minute timer and explain your design aloud as if someone were listening. Record it if you can.
- Do the arithmetic every time. Even a rough estimate changes the design: 100 writes a second and 100,000 writes a second are different systems.
- Rehearse the follow-ups. For every component, ask yourself what happens when it fails and what happens at ten times the traffic.
- Review the transcript. Listening back shows where you rambled, where you skipped requirements and which trade-offs you never mentioned.
Natively helps with the last two. On a mock interview call it transcribes both sides as you speak and can suggest talking points for each question; you can also capture a screenshot of a diagram and ask for an explanation. Afterwards the transcript and notes are saved on your computer so you can review the session. See the system design interview assistant for how it works in a live session, and check the rules of any real interview before using live help in it.
Questions people ask
How long is a system design interview?
Usually 45 to 60 minutes, of which about 35 to 45 are spent on the design itself. The rest is introductions and your questions. Plan your time in blocks: requirements, estimates, high-level design, one or two deep dives, then trade-offs and failure modes.
Do I need to memorize real companies' architectures?
No. Interviewers grade how you scope the problem, justify choices with numbers and reason about trade-offs. Knowing that a real company uses a particular database is far less useful than being able to explain why a key-value store fits a single-key lookup.
Which system design questions come up most often?
URL shorteners, rate limiters, chat systems, news feeds, notification services, ride-hailing, video streaming, file storage and search autocomplete appear again and again in candidates' reports. Each one exercises a different core idea, which is why the guides here are grouped by concept as well as by product.
Where to go next
Practice with the same assistant you would use on a call: it listens, transcribes and suggests answers from your own resume and the job description.
Facts on this page were last checked on . Product details come from the Natively app itself; if something here is out of date, tell us at hello@heynatively.com.
