AlgoInsight

System Design

How to Answer ANY System Design Interview Question

I failed a Google system design round once. I could code. I just couldn't design at scale in forty-five minutes with a stranger watching. The fix wasn't more knowledge - it was a framework.

By Admin2026-06-1811 min readsystem-designinterview-prepframeworkarchitectureestimationscalability

Years before I became the person on the other side of the table, I failed a Google system design round. Not because I couldn't code - by then I could. I failed because the interviewer said "design a system to do X," I stared at the whiteboard, and I didn't know where to start. I jumped straight to databases, doubled back to APIs, forgot to ask what we were even building, and forty-five minutes evaporated into a pile of disconnected boxes. I knew things. I just had no process for turning what I knew into a design under pressure.

What fixed it wasn't learning more distributed systems. It was a repeatable structure - the same one I now watch for when I run loops. Strong candidates don't know more than weak ones nearly as often as they're simply more organized. Here's the framework that turns "design YouTube" from a panic into a checklist.

flowchart TD
    A[1. Clarify requirements<br/>functional + non-functional] --> B[2. Estimate scale<br/>QPS, storage, bandwidth]
    B --> C[3. Define the API<br/>core endpoints]
    C --> D[4. Design the data model<br/>what's stored, where]
    D --> E[5. High-level design<br/>boxes and arrows]
    E --> F[6. Deep dive<br/>where the interviewer pushes]
    F --> G[7. Address bottlenecks<br/>scale, failure, trade-offs]

This flowchart shows a seven-step framework for answering any system design question. Step one is clarifying functional and non-functional requirements. Step two is estimating scale: queries per second, storage, and bandwidth. Step three is defining the API with core endpoints. Step four is designing the data model. Step five is the high-level design with boxes and arrows. Step six is a deep dive where the interviewer pushes. Step seven is addressing bottlenecks: scaling, failure, and trade-offs.

Step 1 - Clarify before you draw anything

The biggest mistake - the one I made at Google - is designing before you know what you're designing. "Design Twitter" is not a spec; it's a prompt. Your first move is to narrow it with questions:

Important: Spending the first 5 minutes on requirements is not wasted time - it's the most important time. It scopes the problem to something solvable and shows the interviewer you don't just start coding boxes the moment you hear a prompt. I've passed candidates largely on the quality of their clarifying questions.

Step 2 - Estimate the scale (the part people skip and shouldn't)

Before you design, get a rough sense of the numbers, because the numbers decide the design. A system for 1,000 users and one for 1 billion are not the same architecture. You do this with back-of-the-envelope math - nobody expects precision, they expect that you can reason about magnitude.

# Back-of-envelope for a Twitter-like service
daily_active_users = 200_000_000
tweets_per_user_per_day = 2
reads_per_user_per_day = 100          # timeline views - read-heavy!

SECONDS_PER_DAY = 86_400
write_qps = daily_active_users * tweets_per_user_per_day / SECONDS_PER_DAY
read_qps  = daily_active_users * reads_per_user_per_day  / SECONDS_PER_DAY

avg_tweet_bytes = 300
daily_storage_gb = daily_active_users * tweets_per_user_per_day * avg_tweet_bytes / 1e9

print(f"Write QPS: ~{write_qps:,.0f}")
print(f"Read QPS:  ~{read_qps:,.0f}")
print(f"Read:Write ratio: ~{read_qps/write_qps:.0f} : 1")
print(f"New storage/day: ~{daily_storage_gb:,.0f} GB")

Run it. The output tells you the most important fact about this system before you've drawn a single box: it's roughly 50:1 read-heavy. That single number drives everything downstream - it tells you to optimize aggressively for reads (cache, precompute timelines) and accept more expensive writes. That's why you estimate. Not to be precise - to surface the constraint that shapes the design.

Step 3 - Define the API

Now lock down the contract. A few core endpoints, just enough to show what the system does:

POST /tweet        { user_id, text }        -> tweet_id
GET  /timeline     { user_id, page }        -> [tweets]
POST /follow       { follower_id, followee_id }

This is quick, but it forces precision. It pins down exactly what data flows in and out, and it gives you and the interviewer a shared vocabulary for the rest of the conversation. Skipping it tends to leave the design vague.

Step 4 - Design the data model

What are you storing, and what shape is it? For our example: a Users table, a Tweets table, a Follows table (who follows whom). This is also where the first real trade-off surfaces - SQL or NoSQL? Given the scale you just estimated and the simple access patterns, you can reason out loud about partitioning the tweets by user, and whether follows belong in a relational table or a wide-column store. The interviewer wants to see you connect the data model to the numbers from Step 2.

Step 5 - High-level design

Now, and only now, draw the boxes. Client → load balancer → application servers → caches → databases. Keep it clean and let the request flow left to right. Walk through one full request - "a user posts a tweet, it goes here, gets written here, fans out to followers like this." A reviewer should be able to follow a single piece of data through your entire system. If they can't, the design is too tangled.

Tip: Narrate as you draw. "The write comes into the load balancer, hits an app server, gets written to the primary DB, and an event goes onto a queue to update follower timelines." Silent box-drawing is hard to evaluate. Thinking out loud is half the score.

Step 6 - Deep dive where they push

You won't get through a clean high-level design before the interviewer zooms in: "How does the timeline actually get built? What happens when a celebrity with 50 million followers tweets?" This is the real test, and it's a good sign - it means they're engaged. Pick the component they point at and go deep: the fan-out strategy, the cache design, the partitioning scheme. Here's where the distributed-systems knowledge you've built actually gets spent.

Step 7 - Bottlenecks, failure, and trade-offs

Close by stress-testing your own design before they have to. "The single database is a bottleneck and a single point of failure, so I'd add read replicas and partition by user. The cache could go stale, so here's my invalidation approach. If this region fails, here's the fallback." Proactively hunting your own weak points is the strongest finish you can give. It's the difference between "I built a thing" and "I built a thing and I understand exactly how it breaks."

Interview: The candidates I write "strong hire" for almost never have more knowledge than the others. They have more structure. They clarify, estimate, design, then attack their own design - calmly, in that order, narrating throughout. The framework is what frees your brain to actually think, instead of panicking about where to start.

The reason this works is that it externalizes the part that used to overwhelm me. When "design YouTube" lands, you're no longer staring at a blank board - you're on step one, asking what features matter, and the structure carries you. Every question becomes the same seven steps with different content poured in. We practice this end-to-end, on real prompts, across System Design Fundamentals - because knowing the building blocks is only half of it. The other half is the process that lets you assemble them when the clock is running.

Go deeper

More articles