The system-design interview framework

The system-design interview is the one most people prepare for wrongly. They memorize architectures — "the Twitter design," "the Uber design" — and then freeze when the prompt is slightly different, because they learned answers instead of a method. What the interviewer is actually evaluating is not whether you can recite a diagram; it's whether you can take a deliberately vague prompt ("design a chat app") and drive it to a defensible design out loud, making trade-offs on purpose and justifying each one. This lesson is the method the rest of this stage applies. Learn the method and every prompt becomes tractable; memorize architectures and you're one curveball from stalling.

The whole thing is a time-management problem as much as a technical one — you have ~45 minutes, and how you spend them is itself part of what's being scored. Here's the budget.

Step 1: Requirements & scope (≈5 min) — don't design yet

The single most common failure is designing before scoping. The prompt is vague on purpose — the interviewer wants to see you turn "design a URL shortener" into a bounded problem by asking questions. Split what you gather into two kinds:

• Functional requirements — what it does. "Users shorten a long URL and get a short one; visiting the short one redirects. Do we need custom aliases? Expiry? Analytics?" Nail down the two or three core features and explicitly defer the rest — scoping out is as valuable as scoping in.
• Non-functional requirements — the properties that actually shape the architecture: scale (how many users, reads/sec, writes/sec), read-vs-write ratio, latency targets, consistency needs, availability. These matter more than the features, because "10 million reads a second, read-heavy, can tolerate slight staleness" dictates a completely different design than "1000 writes a second, must be strongly consistent." Ask for numbers, or state your assumptions and move on.

End this step by stating, in one or two sentences, the bounded problem you're going to solve. If you skip this, everything downstream is unanchored.

Step 2: Estimates (≈5 min) — size the problem

Back-of-the-envelope math, done out loud. The point isn't precision — it's to discover the shape of the problem so your design is proportionate. A system doing 100 requests/second and one doing 1,000,000 are different architectures, and the estimates tell you which you're in. Compute the few numbers that change decisions:

• Traffic — requests/second (take daily actions, divide by ~100,000 sec/day, then multiply peak by 2–10×). This tells you whether one server or a fleet, and whether you need caching and a CDN.
• Storage — bytes/item × items/day × retention. This tells you whether it fits on one database or needs partitioning/sharding.
• Bandwidth and the read/write ratio — a 100:1 read-heavy system screams "cache and replicas"; a write-heavy one screams "ingest path, queues, maybe LSM storage."

Keep round numbers (1 KB, 1 million, 1 billion) and a few reference points in your head (a server handles ~thousands of req/s; Postgres on good hardware does low-thousands of writes/s; RAM is ~100× faster than SSD which is ~100× faster than a cross-region round trip). The estimate's job is to justify the next step's choices — "at 50k reads/sec and a 100:1 ratio, I'll put a cache in front and read from replicas" is the sentence estimates buy you.

Step 3: High-level design (≈10 min) — the boxes

Now sketch the major components and the request flow between them, at the altitude of boxes and arrows: client → load balancer → application servers → cache / database / object storage / queue. Walk the primary flow end to end ("a write comes in, hits the LB, an app server validates it, writes to the DB, enqueues a notification…"). Define the API (the handful of endpoints) and the data model (the core tables/entities) — these two anchor everything and often reveal the real problem. Stay at this altitude; resist diving into any one box yet. The goal is a design that plausibly works and gives you and the interviewer a shared map to then dig into.

Step 4: Deep-dives (≈15 min) — where the interview is actually won

This is the largest block and the one that separates candidates. The interviewer will steer you into one or two components and want depth: how does the redirect actually resolve? how do you generate unique short codes without collisions at scale? how does the feed handle a celebrity with 50 million followers? how do you keep the ledger correct under concurrent writes? This is where every lesson in this curriculum pays off — a deep-dive is you demonstrating you know what's under the box you drew:

• Scaling the data layer: replication, sharding and the shard key, caching strategy and invalidation.
• Correctness under concurrency: locks vs optimistic concurrency, idempotency, the consistency model you need.
• Async and reliability: queues, the outbox, at-least-once + idempotent.

The move that scores: name a trade-off and pick a side with a reason. "I'd shard by user id because the hot query is per-user, accepting that cross-user queries now scatter" beats any amount of hand-waving. Interviewers are listening for "X, because Y, at the cost of Z."

Step 5: Wrap-up (≈5 min) — name your own bottlenecks

Close by critiquing your own design before the interviewer has to: where's the single point of failure, what breaks first under 10× load, what did you deliberately leave out and why, and what you'd monitor. Proactively naming your design's weaknesses reads as senior — it shows you know a design is a set of trade-offs, not a trophy.

Go deeper

• The System Design Primer — The most comprehensive free repo of the framework, estimation cheat-sheets, and worked examples — the standard companion for interview prep, structured much like this stage.
• Hello Interview — system design in a hurry — A tight, modern take on the requirements-to-wrap-up flow with strong emphasis on how to *spend the time* and narrate trade-offs — reinforces the method over memorization.
• Back-of-the-envelope estimation references — The latency and throughput reference numbers (RAM vs SSD vs network, server req/s) that make Step 2 fast and credible instead of guessed.

Check yourself

Answer out loud, as if an interviewer asked. If you hand-wave, reread that section.

1. Why is the interview a test of method rather than memorized architectures? Name the five steps of the framework and roughly how you'd budget 45 minutes across them.
2. In the requirements step, distinguish functional from non-functional requirements, and explain why the non-functional ones (scale, read/write ratio, consistency) shape the architecture more than the feature list.
3. What is the purpose of back-of-the-envelope estimation if not precision? Give an example where the read/write ratio alone flips your high-level design.
4. The deep-dive block is where interviews are won. State the phrase-shaped move that scores (X because Y at the cost of Z) and give one deep-dive example that exercises it.
5. List the four common ways candidates lose, and state the single meta-lesson (about simplicity vs sophistication) that avoiding all four comes down to.
6. How is the Fable case-study series an instance of this exact framework, and why is "the simplest design that meets the requirements, trade-offs named" the answer it models?