Skip to main content

How to Answer a System Design Interview Question

· 4 min read
System Design Lab
Free system design course

"Design Twitter" is not a question with one correct answer — it's a prompt to see how you think. Walking in without a repeatable structure is the single most common reason strong engineers freeze up in this interview format.

The six steps​

  1. Clarify requirements — what does this system actually need to do, and what's explicitly out of scope?
  2. Estimate scale — rough numbers for users, requests per second, and data volume, since scale changes which architecture is even reasonable.
  3. Design the API — the concrete contract between clients and your system, before you design what's behind it.
  4. Model the data — what entities exist, and how are they shaped and related?
  5. Sketch the high-level design — the boxes and arrows: services, databases, caches, queues, load balancers.
  6. Deep-dive and discuss tradeoffs — pick the one or two hardest parts and go deep, naming what you gave up and why.

Skipping straight to step 5 — drawing boxes before you know what you're building for — is the most common failure mode. It produces a generic-looking architecture that doesn't actually fit the problem, because nothing about it was derived from a real requirement or a real number.

Why requirements come first​

"Design a URL shortener" sounds fully specified, but it isn't. Does it need custom aliases? Analytics on click-through? Do links expire? Every one of those answers changes the design. Asking clarifying questions isn't stalling — it's the only way to design for the actual problem instead of an imagined generic version of it. It also directly shapes step 2: you can't estimate scale for a system whose scope you haven't pinned down.

Why scale estimation isn't just for show​

Rough numbers — "let's say 100 million daily active users, 10,000 writes per second at peak" — aren't decoration. They're what tells you whether a single relational database is fine or whether you need to talk about sharding at all. A design that reaches for a distributed, sharded architecture to handle 50 requests per second is over-engineered; a design that proposes a single Postgres instance for a system doing 500,000 writes per second is under-engineered. The numbers are what let you defend why your design is sized the way it is, rather than defaulting to whatever's trendiest.

API before architecture​

Designing the API — the actual request/response shapes a client would call — before drawing any boxes forces you to be concrete about what the system does, from the outside, before you decide how it does it internally. It's also just good API design discipline: get the contract right first, and the implementation has a clear target to satisfy.

The deep-dive is where interviews are actually won or lost​

The first five steps get you to a reasonable, defensible baseline design. The deep-dive is where you show real engineering judgment: picking the one or two genuinely hard parts of the problem — how do we handle a hot shard, how do we keep the feed consistent under concurrent writes, how do we deduplicate at-least-once message delivery — and reasoning through them out loud, including the tradeoffs you're accepting. This is also where topics like database sharding, strong vs. eventual consistency, and rate limiting tend to show up as the specific mechanism you reach for.

What's actually being evaluated​

There is no single "correct" architecture for "design Twitter." Interviewers are grading how you navigate tradeoffs, not whether you land on some canonical diagram. A candidate who clearly names why they chose eventual consistency for a like counter, or why they'd shard by user ID instead of by post ID, is demonstrating exactly the skill the interview exists to test — even if a different, equally defensible design was possible.

Go deeper​

The full lesson walks through each step in more detail, includes a flowchart of the framework, and links out to the specific concepts — APIs, SQL vs. NoSQL, load balancing — that tend to come up inside each step:

👉 Read the full How to Answer a System Design Interview Question lesson — part of the free System Design Lab course.