System Design Interview Questions You Must Know
The system design interview feels open-ended and scary — but ~90% of it reuses the same building blocks and a short list of canonical questions. Learn the framework, master these, and walk in calm.
If you're preparing for a software engineering interview at any serious company, the system design round is often what decides the level — and the offer. The good news? It's far more predictable than it looks. The same system design interview questions come up again and again, and they're all variations on a handful of core ideas.
This guide gives you two things: a repeatable framework for answering any system design question, and the specific questions you must know — with crisp, interview-ready answers. Let's get you confident.
First: a framework you can reuse every time
The single biggest mistake candidates make is jumping straight to boxes and arrows. Don't. Interviewers are scoring your process as much as your answer. Use these six steps, out loud, for every question:
- Clarify requirements. Functional ("users can post and follow") and non-functional ("99.9% uptime, low latency, read-heavy"). Never assume — ask.
- Estimate scale. Rough numbers: users, reads vs writes, data per day. This decides which bottleneck shows up first.
- Define the API. A few endpoints (
POST /tweet,GET /feed). It pins down exactly what the system does. - Design the data model. Key entities and how they relate. SQL or NoSQL — and why.
- Draw the high-level design. Client → load balancer → services → data stores. Keep it simple first.
- Scale it and discuss trade-offs. Now add caching, replicas, sharding, queues — and say what each one costs you.
Say this in the room: "Let me start simple and then scale it." It signals seniority instantly — juniors over-engineer; seniors evolve a design on purpose.
Concept questions you must be able to answer
Before the "design X" questions, interviewers often warm up with fundamentals. Have a one-breath answer ready for each of these.
| Question | What they're really asking | Crisp answer |
|---|---|---|
| What is a load balancer? | Do you know how to scale horizontally? | Distributes traffic across many servers so no single one is overwhelmed; enables failover. |
| Caching — why and where? | Do you reduce load smartly? | Store hot data in memory (Redis) to avoid repeat DB hits; trade freshness for speed via TTLs. |
| SQL vs NoSQL? | Can you pick the right store? | SQL for structured data and transactions; NoSQL for scale, flexible schema, and simple high-volume access. |
| What is sharding? | Can you scale writes/data? | Split data across DBs by a key so each holds a slice; scales beyond one machine. |
| Replication vs sharding? | Do you know the difference? | Replication = copies for read scale & failover; sharding = partitions for write/data scale. |
| CAP theorem? | Do you understand trade-offs? | Under a network partition you choose Consistency or Availability — you can't have both. |
| How to rate limit an API? | Can you protect a service? | Token bucket / sliding window counters in Redis, keyed per user or IP. |
| Why a message queue? | Do you decouple slow work? | Hand off slow tasks (email, encoding) to background workers so requests stay fast. |
If you can speak to that whole table comfortably, you're already ahead of most candidates. Now let's apply it.
The classic "design X" questions
These are the heavyweights. You don't need to memorise full solutions — you need to drive each one through the framework above. Here are the most common, with the key ideas that win points.
Design a URL shortener (TinyURL / Bitly)
The most popular warm-up question in the entire system design interview canon. The whole game is: generate a short, unique code, then redirect fast.
Talking points that score: it's extremely read-heavy, so cache aggressively; generate keys with base-62 encoding of a counter (or a key-generation service to avoid collisions); use a fast key-value store; redirects should be a single cache lookup. Mention analytics and link expiry as extensions.
Design a news feed (Twitter / Instagram)
The core tension is fan-out: when you post, how do your followers see it?
Talking points: fan-out-on-write (push to follower feeds on post) gives fast reads but struggles with celebrities who have millions of followers. Fan-out-on-read (build the feed when requested) is the opposite. The senior answer is a hybrid: push for normal users, pull for celebrities. That nuance is exactly what they want.
Design a rate limiter
A favourite because it's small enough to fully solve in 30 minutes.
Talking points: compare algorithms — fixed window (simple, bursty at edges), sliding window (smoother), and token bucket (allows bursts, most common). Store counters in Redis for speed and so the limit is shared across all servers.
Design a chat app (WhatsApp / Messenger)
Talking points: use WebSockets for real-time, bidirectional messaging (not polling); a presence service for online/offline status; store messages in a write-heavy store; deliver via a message queue so offline users get messages when they reconnect. Mention delivery receipts and end-to-end encryption.
More design questions to know (one idea each)
These round out almost any system design interview prep list:
- Design Uber / a ride-sharing app — geospatial indexing (geohashing) to match nearby drivers.
- Design a notification system — a queue + worker fan-out across email / SMS / push channels.
- Design Dropbox / Google Drive — chunk files, deduplicate, sync with metadata + object storage.
- Design a web crawler — a frontier queue, politeness/rate limits, and dedup of visited URLs.
- Design YouTube / Netflix — object storage + a CDN for video, with transcoding done async.
- Design a typeahead / autocomplete — a trie in memory, cached, ranked by popularity.
- Design a distributed cache — consistent hashing to spread keys and survive node loss.
For each, name the one core challenge and the tool that solves it — that's how you sound like someone who has actually built things.
Numbers worth memorising
Estimation makes or breaks step 2. You don't need exact figures — you need to be in the right ballpark and confident:
| Rule of thumb | Use it for |
|---|---|
| Reads outnumber writes ~100:1 in most apps | Justifying caches and read replicas |
| 1 server ≈ a few thousand concurrent connections | Deciding when to add servers |
| Memory read ≈ 100× faster than disk; cache ≈ 100× faster than a DB query | Explaining why you cache |
| A day ≈ 86,400 seconds (~100k) | Converting "daily users" into requests/second |
How to actually stand out
Knowledge gets you to "hire". These habits get you to "strong hire":
- Think out loud. Silence reads as being stuck. Narrate your reasoning.
- State trade-offs unprompted. "A cache means possibly stale data, which is fine for a feed but not for a bank balance." That single sentence signals maturity.
- Know when to stop. "I wouldn't shard yet — we don't have the scale" is a senior answer, not a cop-out.
- Drive the conversation. Don't wait to be quizzed. Move through your framework and invite the interviewer in.
System design interviews reward calm, structured thinking far more than trivia. You now have the framework and the must-know questions. The only thing left is the part most people skip: practising it out loud, under realistic pressure.