A system design interview is an open-ended 45–60 minute round where you design a large-scale system out loud while an interviewer probes your reasoning. It is not a memory test. Interviewers are scoring how you scope an ambiguous problem, justify trade-offs, and recognise where your own design breaks. This guide gives you a five-phase framework that fits the clock, the 12 prompts that cover almost every real question, and the specific failure modes that sink otherwise strong engineers.
What System Design Interviews Actually Measure
Coding rounds have a right answer. System design rounds do not — which is exactly why candidates find them harder to prepare for. Interviewers at every major company evaluate roughly the same four signals:
Scoping under ambiguity
The prompt is deliberately vague. "Design Twitter" has no single answer until you establish read/write ratio, user count, and which features are in scope. Strong candidates narrow the problem before designing. Weak candidates start drawing boxes.
Trade-off reasoning
There is no correct database choice — only a defensible one. Saying "I will use Cassandra because writes dominate 100:1 and I can accept eventual consistency on the feed" scores. Saying "I will use Cassandra because it scales" does not.
Depth on at least one component
Interviewers want to see you go three levels deep somewhere. A design that stays at the box-and-arrow layer for 45 minutes reads as surface knowledge, however broad.
Awareness of your own weak points
Naming the bottleneck before the interviewer does is the single strongest signal available to you. "The fan-out on write will break for celebrity accounts — here is how I would handle that" is what a senior engineer sounds like.
The Five-Phase Framework
Announce each phase out loud as you enter it. This does two things: it shows structure, and it gives the interviewer a cheap moment to redirect you before you spend ten minutes in the wrong place.
Clarify requirements — 5 to 8 minutes
Separate functional from non-functional. Functional: what can a user do? Non-functional: how many users, read/write ratio, latency target, consistency tolerance, availability target. Write the answers where you both can see them. Never skip this phase, even if the prompt seems obvious.
Estimate scale — 3 to 5 minutes
Convert the user count into requests per second, storage per year, and bandwidth. You are not trying to be accurate; you are establishing which order of magnitude the design has to survive. 1,000 writes/second and 1,000,000 writes/second lead to genuinely different architectures, and this is where you find out which one you are building.
Define the API and data model — 8 to 10 minutes
List three to five endpoints with their parameters, then the core entities with their key fields and access patterns. The access patterns are the point: they determine your storage choice, so derive the database from them rather than announcing it up front.
Draw the high-level architecture — 10 to 12 minutes
Client, load balancer, application tier, cache, primary datastore, async workers, object storage. Draw the request path for one write and one read end to end. Keep it deliberately boring — this phase should contain no clever ideas, only a correct baseline you can then stress.
Deep-dive and stress the design — 10 to 15 minutes
Pick the component most likely to break and go deep: sharding key and its hot-spot risk, cache invalidation strategy, what happens when a worker dies mid-job, how you handle the 99th-percentile user. If the interviewer has a favourite area they will steer here; otherwise choose the bottleneck you already identified.
Time discipline is part of the score
Candidates who spend 25 minutes on requirements and never reach an architecture fail the round even when their questions were excellent. Keep a rough eye on the clock and force yourself forward. An imperfect complete design beats a perfect third of one.
Capacity Estimation: The Six Numbers Worth Memorising
You do not need to memorise system architectures. You do need enough arithmetic anchors to do back-of-envelope maths without stalling.
| Quantity | Anchor | Use it for |
|---|---|---|
| Seconds per day | ~86,400 (round to 100,000) | Daily events → requests/second |
| Seconds per month | ~2.5 million | Monthly volume → storage growth |
| Short DB row | ~100 bytes | Metadata, follows, likes, IDs |
| Text post | ~1 KB | Tweets, messages, comments |
| Photo / thumbnail | ~1 MB / ~10 KB | Media storage and CDN bandwidth |
| One app server | ~1,000 requests/second | How many servers the tier needs |
A worked example, said out loud in about 40 seconds: "100 million daily active users, each posting twice a day, is 200 million writes per day. Divided by 100,000 seconds, that's 2,000 writes per second average, so call it 6,000 at peak. At 1 KB per post that's 200 GB per day, roughly 70 TB per year before replication. Reads are 100 times writes, so 600,000 reads per second at peak — that number tells me the read path has to be cache-first, and it is where I will spend my deep-dive."
The 12 Questions That Cover Almost Everything
Most prompts are recombinations of a small set of primitives. Prepare these twelve and you will recognise the underlying shape of nearly any question you are given.
Write-heavy / fan-out
- Design a news feed (Twitter, Instagram)
- Design a chat application (WhatsApp, Slack)
- Design a notification service
- Design a metrics and monitoring pipeline
Read-heavy / lookup
- Design a URL shortener
- Design search autocomplete
- Design a distributed cache
- Design a video streaming platform
Coordination / correctness
- Design a rate limiter
- Design a payment ledger
- Design ride-hailing dispatch
- Design a web crawler
The grouping matters more than the list. Write-heavy fan-out problems turn on whether you fan out on write or on read. Read-heavy lookup problems turn on cache strategy and invalidation. Coordination problems turn on what you do when two nodes disagree. Identify which family a prompt belongs to in the first two minutes and you already know where your deep-dive will land.
Six Failure Modes That Sink Strong Engineers
Designing before scoping
The most common failure by a wide margin. Drawing an architecture for 100 million users when the interviewer wanted an internal tool for 10,000 does not read as ambitious — it reads as an inability to scope. Ask first.
Reciting a memorised architecture
Interviewers ask these questions dozens of times and can spot a rehearsed answer immediately. They will then push on an unusual constraint specifically to see whether you understood what you recited. Derive your design from the requirements you just established, in the room.
Adding components with no justification
Kafka, Redis, Elasticsearch, and a service mesh in the first diagram signals pattern-matching rather than reasoning. Every box needs a one-sentence reason tied to a requirement. If you cannot give one, remove the box.
Staying at the box-and-arrow layer
Breadth without a single deep-dive reads as shallow. Choose one component and go three levels down — the actual sharding key, the actual eviction policy, the actual failure behaviour.
Going silent while thinking
Thirty seconds of silence is unscoreable. Narrate the dead ends too: "I considered a single Postgres primary here, but 6,000 writes per second with this row size will saturate it, so I need to shard." The rejected option is itself a signal.
Defending a design after it breaks
When an interviewer surfaces a flaw, they are usually testing whether you can update. Concede quickly and adapt. "You are right, celebrity fan-out breaks this — let me switch those accounts to fan-out on read" scores far better than justification.
How to Practise So It Transfers
Reading system design content builds recognition, not fluency. The round is a live performance under time pressure, so practise the performance rather than the material. Three rules make the difference:
- Always out loud, always timed. Set 45 minutes and talk through the whole thing, even alone. Silent reading builds an illusion of readiness that collapses the moment you have to narrate.
- Repeat the same prompt three times. The first run finds your gaps, the second builds structure, the third builds pace. Repetition on one prompt beats single passes on ten.
- Get interrupted. Real interviewers cut in with "why not SQL here?" at the worst moment. Practising without interruption trains a monologue, and the round is a conversation.
That last point is the hardest to arrange alone, which is where AI practice is genuinely useful — you can run the same prompt repeatedly, at any hour, and be pushed on your reasoning without booking anyone's time. We have compared AI and human coaching honestly here, including where a human still wins: reading how you come across under pressure is not something a model does well yet.
If you are preparing for big-tech loops specifically, the system design round rarely stands alone — it sits alongside coding and behavioral rounds that carry their own scoring rubrics. Our FAANG preparation roadmap covers how to sequence all three without burning out, and the behavioral question guide covers the STAR structure that the non-technical rounds are graded against.
Practise system design out loud, as often as you need
Amigo runs unlimited timed practice from your resume and target role, then supports you in the live interview with structured answers streamed in real time.
Try Amigo free →Frequently Asked Questions
What is a system design interview?
A system design interview is a 45–60 minute open-ended round where you design a large-scale system — such as a URL shortener, news feed, or chat app — while explaining your reasoning. It assesses how you handle ambiguity, make trade-offs, and reason about scale, not whether you recall a specific architecture.
How do you structure a system design interview answer?
Use five phases with a rough time budget: clarify requirements (5–8 min), estimate scale (3–5 min), define the API and data model (8–10 min), draw the high-level architecture (10–12 min), then deep-dive on bottlenecks and trade-offs (10–15 min). Announce each phase out loud so the interviewer can redirect you early.
What are the most common system design interview questions?
Design a URL shortener, a news feed, a chat application, a rate limiter, a distributed cache, a notification service, a ride-hailing dispatch system, a video streaming platform, a payment ledger, a search autocomplete, a web crawler, and a metrics/monitoring pipeline. Most other prompts are variations on these primitives.
Do I need to memorise numbers for capacity estimation?
You need about six: roughly 100 bytes per short database row, 1 KB per text post, 1 MB per photo, ~86,400 seconds in a day, ~2.5 million seconds in a month, and 1 server handling on the order of 1,000 requests/second. Everything else you derive out loud from the interviewer's stated numbers.
What is the most common reason candidates fail system design interviews?
Jumping straight to a diagram without clarifying requirements. Designing a globally distributed system when the interviewer wanted 10,000 users, or a single-server design when they wanted 100 million, both read as an inability to scope. Spend the first five minutes on questions.
How senior do you need to be for a system design round?
Most companies introduce system design at mid-level (roughly 3+ years) and weight it heavily from senior upward. At staff level and above it is often the round that determines your final level, because it is the clearest signal of judgment on ambiguous problems.
Found this useful?
Share it with someone preparing for an interview.
