A Framework for Any Design Problem

The biggest mistake in a system design interview isn’t getting an answer wrong — it’s not having a method. People who freeze are the ones trying to recall “the YouTube architecture” from memory. People who do well run the same process on every problem and let the design fall out of it.

Here’s that process. Seven steps, always in this order.

1. Clarify requirements

Never start designing. Start asking. Pin down what the system must do (functional requirements) and what qualities it must have — scale, latency, availability, consistency (non-functional requirements). These two lists are the entire foundation; the next lesson is dedicated to them.

A good clarifying question changes the design. “Do we need to show exact like counts, or is approximate fine?” is worth more than ten lines of code — the answer decides whether you need strong consistency or can cache.

2. Estimate scale

Do back-of-the-envelope math: daily active users → requests per second → storage per year → bandwidth. You’re not after precision; you’re after the order of magnitude that tells you whether one database is enough or you need 50. We cover this in the Back-of-the-envelope lesson.

3. Define the API

Write the handful of endpoints the system exposes. This forces clarity about what the client actually needs before you worry about internals. Keep it to the core operations:

// Designing a URL shortener? The whole product is two endpoints:
POST   /urls        { longUrl }            -> { shortCode }
GET    /:shortCode                         -> 302 redirect to longUrl

// In Express, the contract is this small — everything else
// (hashing, storage, caching) is an implementation detail behind it.
app.post('/urls', (req, res) => { /* create short code */ });
app.get('/:code', (req, res) => { /* look up & redirect */ });

4. Design the data model

What are the entities, and which store holds each? This is where you justify SQL vs NoSQL, what to index, and what to denormalize. A users table and a tweets table look obvious — the interesting decision is how the timeline is stored, because that’s what has to scale.

5. High-level architecture

Now — and only now — draw the boxes: load balancer, app servers, caches, databases, queues, workers. This is the canonical skeleton from the intro, specialized for this problem. Walk the interviewer through one request end to end.

6. Deep-dive the hard parts

Every system has 2–3 genuinely hard pieces. Twitter’s is timeline fan-out. YouTube’s is video transcoding and delivery. WhatsApp’s is presence and delivery guarantees. Pick the hard parts and go deep — this is where senior candidates separate from junior ones.

7. Bottlenecks & tradeoffs

Close by attacking your own design. What breaks first under 10× load? What’s the single point of failure? Which tradeoff did you make and why? Naming your design’s weaknesses is a strength, not an admission of failure.

Budgeting a 45-minute interview

You don’t get unlimited time. Roughly:

Every case study in this track is structured along these same seven steps. By the tenth one, the framework will be automatic — which is exactly the point.