System Design Interview Questions: What Is Actually Being Graded

Four problems that test judgement rather than recall. Each group opens with what the interviewer is grading, then gives you a decision to make — the options are about what to ask and what to trade, not which diagram to draw.

System design is the one interview round with no answer key, which is why memorising architecture diagrams fails: the follow-up is always 'what if the traffic is ten times that?' and a recited design cannot bend. What is actually graded is whether you turn a vague prompt into requirements, name the cost of every choice, and fix the current bottleneck rather than all possible bottlenecks.

The questions here are framed as decisions rather than facts. There is a defensible answer to each, but the explanation focuses on the reasoning an interviewer is listening for — and on the sentence that usually earns the point.

If you are preparing seriously, pair this with the data-layer questions on our SQL page: sharding, replication and read paths are where system design and SQL knowledge meet, and interviewers move between them freely.

Three areas, four decisions

The first five minutes decide the interview

1 problem

The opener is vague on purpose. Candidates who start drawing boxes have already lost points; candidates who spend three minutes turning the prompt into numbers have already earned them. Ask for scale (daily active users, reads vs writes, peak multiplier), for latency expectations, and for what must never be lost. Those answers determine every later decision, and stating that link out loud is what separates a designed system from a recited one.

How it gets asked: "Design a URL shortener" · "Design a news feed" — deliberately vague openers

Q1

The interviewer says only: 'Design a URL shortener.' What is the strongest first move?

  1. ADraw the architecture diagram you memorised, then adjust
  2. BAsk for scale, read/write ratio and latency targets, then state how those numbers will drive your choices
  3. CStart with the database schema, since storage is the core
  4. DAsk which cloud provider they use
▶Show answer & reasoning

Better answer: B. Ask for scale, read/write ratio and latency targets, then state how those numbers will drive your choices

🐱 Requirements first, and — crucially — say why you are asking: 'if reads outnumber writes 100:1, caching carries the design; if writes are heavy, the ID generation strategy does.' That sentence shows you understand that a system design has drivers, which is the actual thing being graded. (A) is the most common failure mode; the memorised diagram cannot answer 'what if we 10x?', which is the question that always follows.

Trade-offs you must be able to name

2 problems

There is no right answer to 'SQL or NoSQL' — there is only a defended one. The graded skill is naming what you give up: choose strong consistency and you pay in availability during a partition; choose a cache and you inherit staleness and an invalidation problem; shard and you make cross-shard queries expensive. Say the cost out loud before the interviewer asks, and the follow-up becomes a conversation instead of a test.

How it gets asked: "SQL or NoSQL?" · "What does CAP mean for this design?" · "Cache invalidation strategy?"

Q2

You propose adding a cache in front of the database. What must you volunteer next?

  1. AThe exact cache library and its version
  2. BThe invalidation strategy and what a stale read would cost this product
  3. CThat caching always improves performance
  4. DNothing — caching is uncontroversial
▶Show answer & reasoning

Better answer: B. The invalidation strategy and what a stale read would cost this product

🐱 A cache is a correctness trade, not a free speedup: you are choosing to sometimes serve old data. Naming the invalidation approach (TTL, write-through, explicit bust on write) and, more importantly, whether this product can tolerate a stale read — a stale follower count is fine, a stale account balance is not — is what turns 'add a cache' from a buzzword into a decision. Library choice (A) is the least interesting part and rarely asked.

Q3

Which statement about CAP is accurate enough to say in an interview?

  1. AYou must permanently pick two of consistency, availability and partition tolerance
  2. BPartitions happen whether you like it or not; the real choice is what to do during one — refuse writes (consistency) or accept them and reconcile (availability)
  3. CCAP proves NoSQL is faster than SQL
  4. DCAP applies only to distributed caches
▶Show answer & reasoning

Better answer: B. Partitions happen whether you like it or not; the real choice is what to do during one — refuse writes (consistency) or accept them and reconcile (availability)

🐱 The 'pick two' phrasing is the version most candidates recite and it is misleading: in any real distributed system partitions are a fact, not an option, so P is not something you trade away. The decision you actually make is the behaviour during a partition. Saying it this way signals you have operated a distributed system rather than read a summary of one — and it sets up the natural follow-up about eventual consistency.

Scaling the read path, then the write path

1 problem

Scaling questions have a conventional order because reads usually outnumber writes: cache first, then read replicas, then shard the writes, then split services. What is graded is whether you can identify the current bottleneck rather than applying all four at once. Say which component saturates first and what metric would tell you — that turns a shopping list into an engineering answer.

How it gets asked: "It works for 1,000 users. Now make it work for 10 million." · "Where does it break first?"

Q4

A read-heavy service is slowing down. Which sequence shows the better instinct?

  1. AShard the database immediately — it is the most scalable option
  2. BMeasure to find the bottleneck, then cache, then add read replicas, and only shard when writes are the constraint
  3. CRewrite it as microservices first
  4. DUpgrade to the largest instance and revisit later
▶Show answer & reasoning

Better answer: B. Measure to find the bottleneck, then cache, then add read replicas, and only shard when writes are the constraint

🐱 Sharding is the most expensive and least reversible step: it complicates every cross-partition query and every transaction, so it belongs last, after cheaper wins on a read-heavy workload. The word interviewers listen for is 'measure' — a candidate who names the metric before the remedy is describing engineering; one who leads with sharding or microservices is describing a resume. (D) is not wrong as a stopgap, but say that it buys time rather than solving anything.

Keep going

SQL interview questionsWhere system design meets the data layer: joins, indexes and read paths.Python interview questionsThe language round that usually precedes the design round.Logical reasoning test (20 Q, 20 min)Structured reasoning under a clock — the habit design rounds reward.

System design interviews — FAQ

How do I start a system design interview?

With requirements, out loud: scale, read/write ratio, latency targets, and what must never be lost — plus a sentence on how those numbers will drive your choices. Three minutes here saves the whole interview.

Do I need to memorise real architectures?

Knowing common patterns helps, but reciting one is a trap because it cannot answer 'what if we 10x?'. Learn the components and their costs instead: cache, replica, shard, queue, CDN — and what each one gives up.

How much depth on CAP?

Enough to avoid the 'pick two' oversimplification. Partitions are a given; the decision is how the system behaves during one. That framing alone puts you ahead of most candidates.

What is the most common mistake?

Drawing before asking. The second most common is applying every scaling technique at once instead of naming which bottleneck you are addressing and how you would measure it.