The first system design interview I failed, I started drawing boxes about ninety seconds in. Load balancer, three app servers, a database, a cache. It looked like every diagram I had studied. The interviewer let me run for fifteen minutes and then asked how many users the system had. I did not know. I had never asked.
That is the mistake almost everyone makes, and it is not a knowledge gap. It is a process gap. I have since sat on the other side of the table for a lot of these interviews, and the candidates who do well are rarely the ones who know the most technology. They are the ones who behave like an engineer who has actually had to build the thing.
Here is the structure I use, both as a candidate and as the thing I look for when interviewing.
Spend the First Ten Minutes Not Designing
"Design Twitter" is not a problem statement. It is an invitation to ask questions, and the questions are graded more heavily than the diagram.
What I ask, in roughly this order:
Which features, exactly? Twitter is a hundred products. Posting, timeline, follow, search, DMs, notifications, trends. Pick three and say out loud that you are picking three.
How many users? Daily actives, not registered. Ten thousand and ten million are different systems, and half the "right answers" flip between them.
Read or write heavy? This single question determines most of your architecture. A timeline is roughly a hundred reads per write; that ratio is the whole design.
How fresh must the data be? Does a new post need to appear in a follower's feed in one second, or is thirty seconds fine? Nobody offers this and it changes everything.
What can we lose? A dropped analytics event is fine. A dropped payment is not.
Write the answers in a corner of the board. You will refer back to them, and doing so is itself a signal — it shows the design is being driven by requirements rather than by memory.
Do the Arithmetic, Roughly and Out Loud
Back-of-envelope numbers are where candidates either become credible or do not. You do not need precision. You need the order of magnitude, because the order of magnitude decides whether this fits on one machine or needs a fleet.
10M daily active users
Each posts ~2/day → 20M writes/day → ~230 writes/sec
Each reads ~100/day → 1B reads/day → ~11,600 reads/sec
Peak ≈ 3x average → ~35,000 reads/sec
Post row ≈ 300 bytes
20M × 300B ≈ 6 GB/day → ~2 TB/year (fits on one big disk; not a sharding problem yet)
Hot set: last 48h of timelines ≈ a few hundred GB → fits in a Redis cluster
Look at what those five lines just decided. 230 writes/sec is nothing — a single Postgres instance handles that comfortably. 35,000 reads/sec is a lot, so reads need caching and replicas. And 2TB a year means you are not sharding on day one, which kills a whole branch of over-engineering before you draw it.
That is the point of the arithmetic. Not to be right, but to stop yourself designing for a scale that does not exist.
Start Simple, Then Break It On Purpose
The strongest pattern I have seen candidates use: draw the simplest thing that could work, then attack it yourself.
One server, one database. Then: "This falls over when the app server dies, so let me add a second one and a load balancer. Now sessions cannot live in memory, so they move to Redis. Reads are the problem, not writes, so I add read replicas — which means the timeline can be a few hundred milliseconds stale, and we agreed that is acceptable."
Each step has a stated reason. That is what separates a design from a memorised diagram, and it also gives the interviewer places to interrupt you, which is what they are trying to do.
The candidates who struggle draw the final architecture immediately — Kafka, sharded databases, a CDN, six services — and then cannot explain why any of it is there.
The Fan-Out Question Comes Up Constantly
Nearly every feed, notification or timeline question is the same underlying trade-off, so it is worth having a real answer ready.
Fan-out on write: when someone posts, push it into every follower's precomputed timeline. Reads become a single fast lookup. Writes get expensive, and a user with ten million followers means ten million writes for one post.
Fan-out on read: store posts once, and build the timeline by querying everyone a user follows at read time. Writes are cheap. Reads are expensive and get slower as people follow more accounts.
The answer interviewers want is the hybrid, and more importantly the reasoning: fan out on write for normal accounts because reads dominate, and fan out on read for the small number of celebrity accounts because the write amplification is unacceptable. Merge the two at read time.
Being able to say "we do different things for the 99.9% and the 0.1%, and here is where the line is" is worth more than any specific technology name.
Name the Trade-Off, Every Time
The single habit that most improves how a design is received: never present a choice without its cost.
"I will add a cache" is weak. "I will add a cache, which means the data can be stale for up to sixty seconds and I need an invalidation strategy on update — I would use write-through here because the read-after-write case matters for your own posts" is a different answer entirely, and it is not longer by much.
Same for everything else. Replicas buy read throughput and cost you consistency. Queues buy resilience and cost you immediate feedback. Sharding buys write capacity and costs you cross-shard queries and joins. Microservices buy independent deployment and cost you distributed debugging.
If you say the cost before the interviewer asks, you have demonstrated the thing they are actually testing.
What I Look For When I Am Interviewing
Being direct about the scoring, because it is less mysterious than people think.
Did they ask before they drew? A candidate who designs without requirements will do the same thing on my team.
Can they estimate? Not exactly — but do they know that 10M users a day is roughly a hundred writes a second rather than a hundred thousand?
Do they know what they do not know? "I have not run Kafka in production, but I would use it here for replay and multiple consumers" is a strong answer. Bluffing depth is the fastest way to lose me, because the follow-up question always finds it.
Do they design for the stated scale? Proposing sharding for a system with four thousand users tells me they will over-engineer real work too.
Do they handle being wrong well? I will push back on something, sometimes when the candidate was right. What I want to see is engagement with the argument, not instant capitulation and not defensiveness.
How to Prepare Without Memorising
Memorising twenty famous architectures is the common approach and it is fragile — the interviewer only has to ask "why" twice.
What worked for me was smaller and more useful: get genuinely comfortable with about eight building blocks — load balancer, cache, queue, replica, shard, CDN, object store, search index — such that for each one you can say what problem it solves, what it costs, and when it is the wrong choice. Then practise the arithmetic until estimating is quick. Then talk through a design out loud, on a whiteboard, with someone allowed to interrupt.
The interview is not testing whether you have seen the system before. It is testing whether you would make sensible decisions on a system nobody has seen before — which is, after all, the actual job.
