How to Answer System Design Interview Questions

Why system design interviews are different

A coding question usually has a correct answer; a system design question rarely does. The prompt is deliberately underspecified — "design a URL shortener" leaves out scale, budget, and half the requirements on purpose, because the interviewer is evaluating whether you supply the missing pieces through questions and stated assumptions, not whether you guess the ones they had in mind.

That means the diagram you end up with matters less than how you got there: what you clarified first, how you estimated scale, and whether you named the trade-offs behind each decision instead of presenting it as the only option.

A five-step framework

1. Clarify requirements. Separate functional requirements (what the system does) from non-functional ones (how fast, how available, how consistent). Ask about read/write ratio, expected scale, and whether strong consistency actually matters for this use case — many systems can tolerate eventual consistency, and saying so is a signal, not a shortcut.

2. Estimate scale. Rough, defensible back-of-envelope numbers — daily active users, requests per second, storage growth per year — ground every decision that follows. Precision doesn't matter; showing the arithmetic does.

3. Sketch the high-level architecture. A client, an API or load-balanced service layer, a primary data store, and a cache in front of it covers most first passes. Add a queue or a separate service only once you can justify why the simple version doesn't hold.

4. Go deep on one or two components. Interviewers almost always push into one area — a schema, an indexing choice, a cache invalidation strategy. Treat the push as the interview's real content, not a detour from your diagram.

5. Name the trade-offs explicitly. SQL versus NoSQL, strong versus eventual consistency, synchronous versus asynchronous processing, push versus pull — every one of these has a cost somewhere. Stating the cost out loud, even when you still make a clear choice, is usually worth more than the choice itself.

Worked example: a URL shortener

Requirements first: functional requirements are simple — shorten a long URL, redirect a short one — but the non-functional ones drive the design: redirects need to be fast and highly available, while the write path (creating a new short link) can tolerate more latency.

Scale estimate: assume a generous 100 million new links a month and a 100:1 read-to-write ratio. That's roughly 40 writes per second and 4,000 reads per second at peak — small enough that a single well-indexed database can likely handle writes, while reads clearly need a cache.

Architecture: two endpoints. POST /links accepts a long URL and returns a short key; GET /:key looks up the key and redirects. Key generation has two common approaches: a random string with a collision check on insert, or a monotonic counter encoded in base62, sharded across writers so two nodes never generate the same key. Both are defensible; state which one you picked and why.

The trade-off worth naming out loud: a 301 (permanent) redirect lets browsers cache it, cutting load on your servers, but you lose the ability to count clicks server-side on repeat visits. A 302 (temporary) redirect always hits your server, costing more capacity but preserving accurate click analytics. Neither is "correct" — the requirement decides.

Worked example: a chat application

Requirements first: clarify whether you need 1:1 messaging, group messaging, or both; whether messages must arrive in strict order; whether you need delivery receipts and online presence; and whether offline users need push notifications or just see messages on next login.

Scale estimate: for, say, 10 million daily active users sending an average of 20 messages a day, that's roughly 200 million messages a day, or about 2,300 messages per second at a steady average — with real traffic, expect peaks several times higher, which is worth stating explicitly.

Architecture: a gateway layer holds persistent WebSocket (or long-polling, as a fallback) connections from clients. Messages get published onto a queue or log, partitioned by conversation, and persisted to an append-only per-conversation store. For group chats, decide between fan-out on write (push the message to every recipient's inbox immediately, favoring fast reads) and fan-out on read (store once, assemble per reader on demand, favoring simpler writes at very large group sizes) — a well-known trade-off worth naming by name.

Presence (who's online) is typically handled with a lightweight heartbeat and a pub-sub layer rather than a database write per status change, since presence data is high-volume and doesn't need durability. The trade-off worth naming here: at-least-once delivery (a message might arrive twice, so clients need to de-duplicate) is far simpler to build than exactly-once delivery, and most chat products accept that trade for the simplicity.

Common mistakes

Jumping straight to a diagram before clarifying requirements is the most common one — it produces a design that answers a question the interviewer didn't ask. A close second is going silent while thinking; narrate your reasoning even when it's incomplete, since the narration is most of what's being graded.

A third mistake is ignoring a constraint the interviewer already gave you — if they said "assume 1 billion users" and your design quietly assumes a single database server, that mismatch will get noticed. The fourth is presenting a design with no trade-offs at all, as if every decision were obviously correct; naming the road not taken is part of the answer, not padding.

Keep going

• System design interview assistant

  Practice this framework against live prompts.

• How to prepare for a technical interview

  The loop, a study plan, and the day itself.

• All guides

  Back to the index.