System design: how to think out loud when you're not an architect
System design doesn't grade the right answer — there isn't one. It grades how you narrow a vague problem, how you estimate, and whether you name trade-offs out loud. The round, minute by minute.
The central misunderstanding: candidates think they're being asked for the correct architecture. There is no correct architecture — there's a solution to constraints you established yourself.
What's graded is the process: how you narrow a vague problem, which questions you ask, whether you can estimate orders of magnitude, whether you name trade-offs out loud, and whether you know where your design breaks.
That's good news if you've never designed distributed systems. The process is learnable in two weeks; experience isn't.
The 45-minute structure
| Minutes | What you do | Typical mistake |
|---|---|---|
| 0–5 | clarify requirements | drawing boxes immediately |
| 5–10 | estimate load | skipping it and designing in a vacuum |
| 10–20 | high-level diagram | diving into one piece too early |
| 20–35 | deep dive on one component | spreading thin across all of them |
| 35–42 | bottlenecks and scaling | never getting there |
| 42–45 | wrap-up and what you'd improve | waiting silently for a verdict |
Keeping that grid in mind is worth doing literally: half the failures aren't ignorance, they're twenty minutes spent on the first component that came to mind.
Step 1: narrow the problem
"Design Twitter" isn't a task, it's an invitation to ask questions.
Functional requirements. What exactly are we building — posting, a feed, follows, search, notifications? Say explicitly what's in scope and what isn't. "We're not designing direct messages" is a good sentence: it narrows the problem and shows you're managing the clock.
Non-functional. How many users, read-to-write ratio, acceptable latency, whether consistency or availability wins, how long data must live.
If the interviewer says "you decide", state an assumption and move: "I'll assume 10 million daily actives, reads outnumbering writes a hundred to one — correct me if that's off." That's a strong move: you didn't stall, you fixed the inputs.
Step 2: do the arithmetic
Back-of-envelope estimation separates a technology conversation from an engineering one. Do it out loud and roughly.
On those inputs: 10M daily actives reading 10 feeds a day is 100M reads per day. Divided by 86,400 seconds, about 1,200 requests per second on average, with a peak maybe three times higher — call it 3,500.
Writes are a hundred times smaller: roughly 12 per second. That alone tells you this is a read-heavy system, and the real questions are caching and how the feed is assembled.
Storage: a kilobyte per post, a million posts a day, so a gigabyte a day, a terabyte over three years. Which means the data is small and there's nothing to shard yet.
Those four numbers — average rps, peak, read/write ratio and storage — are worth more than half an hour of microservice talk.
Step 3: start simple
Draw the minimum that works: client, load balancer, application service, database, cache. That's it.
Then add components only in response to a named problem:
- a cache because reads outnumber writes a hundred to one;
- a queue because notification fan-out doesn't need to be synchronous;
- object storage and a CDN because images shouldn't travel through the app;
- a search index because full-text search would kill the primary database.
The reverse order — ten boxes first, justification later — is the most visible mistake in the round. The interviewer hears a memorised diagram instead of thinking.
Step 4: say the trade-offs out loud
This separates mid from senior more reliably than technology knowledge. Every decision has a price, and the price should be spoken.
Consistency versus availability. "The feed can lag a few seconds — fine for a social network. Not fine for a wallet balance."
Cost versus latency. "We can fan out on write: fast reads, expensive writes for accounts with millions of followers. Or fan out on read: cheaper, slower."
Complexity versus speed. "We don't need sharding yet — a terabyte fits on one node. Start with a single database and a read replica."
That last sentence is strong on its own. A candidate who deliberately doesn't over-build scores higher than one who draws Kubernetes and five microservices in the first minute.
Six phrases that read as senior
- "Before designing, let me pin down the scope: what's in and what's out."
- "I'll assume these numbers — correct me if the order of magnitude is different."
- "The simplest thing that works here is…"
- "This breaks when…" — followed by a specific condition.
- "Before optimising that, I'd measure…"
- "That's out of scope for 45 minutes, but I'd come back to…"
All six are about managing uncertainty, which is what the round actually tests.
Five ways to fail
Thinking silently. The round is called thinking out loud. A pause longer than ten seconds reads as nothing at all — the interviewer can't tell if you're stuck or calculating.
Designing for a billion when asked for ten thousand. Over-engineering reads as no sense of proportion.
Asking nothing. It means you're solving a different problem than the one intended.
Drowning in one component. Half an hour on the database schema and the conversation never reaches bottlenecks.
Arguing with the interviewer. "Why not something simpler?" is a hint, not an attack. Discuss it rather than defending your first draft.
A two-week preparation plan
Take five canonical problems: URL shortener, social feed, chat, rate limiter, file storage. They cover most of the mechanics that get asked.
Work each through the same grid — requirements, numbers, simple diagram, deep dive, bottlenecks — and do it out loud with a 45-minute timer. The gap between understanding a design and delivering it in 45 minutes is large: in your head the diagram assembles instantly, in speech it falls apart.
Five problems aren't the whole set: every company has its favourites. Open the question bank, filter by system design and by the company you're interviewing with, and see what they actually asked.
That's what rehearsal is for — mock interviews with a timer and a debrief give you the pacing feedback you can't give yourself. If unfamiliar technology comes up in the real round, a live prompt can supply a definition, but you'll still be doing the designing: reading is audible, and it collapses on the first follow-up.
FAQ
What does a system design interview actually grade?
Not the correct architecture — there isn't one — but the process: clarifying requirements, estimating load, choosing components in response to named problems, stating trade-offs, and knowing where the design breaks.
How should I start my answer?
By narrowing scope: what's in and out, how many users, read-to-write ratio, latency and consistency requirements. If the interviewer won't answer, state an assumption and work from it.
Do I need to estimate load?
Yes, and it's one of the clearest markers of a strong answer. Four numbers suffice: average requests per second, peak, read/write ratio and storage volume. Rough and out loud.
What if I don't know a technology?
Describe its role rather than its name: "we need a queue here so the fan-out isn't synchronous." The round tests understanding of the problem, not familiarity with a specific product.
How do I prepare with no design experience?
Work five canonical problems through one structure and say each out loud against a 45-minute timer. The process is trainable in a couple of weeks, and the process is what's being graded.
Is it acceptable to start with a simple solution?
It's preferred. A deliberate "we don't need sharding yet, let's start with one database" scores higher than five microservices in minute one, because it shows a sense of proportion.
