SWE Interview Prep / System Design
System Design Interview Questions — A Beginner's Guide With Real Examples
Most mid-level engineers fail system design interviews not because they can't build systems — but because they don't know what the interviewer is evaluating. It's not the right answer. It's the right process.
What interviewers actually evaluate
Handling ambiguity
Do you ask clarifying questions before designing? Jumping straight to architecture is a red flag.
Scale estimation
Can you estimate QPS, storage, and bandwidth — and use those numbers to make design decisions?
Trade-off reasoning
Why SQL vs NoSQL? Cache-aside vs write-through? The reasoning matters more than the choice.
Communication clarity
Can you explain your design to a non-specialist? Whiteboard thinking out loud is a skill.
Failure mode awareness
What breaks at scale? What's the single point of failure? Proactively identifying these impresses.
Prioritisation
You'll never finish designing everything. Can you identify the most important parts to go deep on?
The 5-step framework for every system design answer
Clarify requirements
Spend 3–5 minutes asking questions. Who are the users? Scale: how many requests/second? Read-heavy or write-heavy? What are the latency SLAs? What features are in scope for today's session? Interviewers expect this.
Estimate scale
Back-of-envelope numbers drive design. '10M daily active users, each making 5 requests → ~580 QPS. At 1KB per request → 580KB/s bandwidth. If we store 1 year of data at 1KB/request → ~18TB.' These numbers tell you whether you need sharding, CDN, or distributed storage.
High-level design
Draw the core components: clients, load balancer, application servers, database, cache. Don't over-engineer at this stage. Get the happy path working first on the whiteboard.
Deep dive
Pick 2–3 components to go deep on — ideally the ones most relevant to the role or most technically interesting. The interviewer will often guide you here. Show trade-offs.
Review and iterate
Walk back through your design. What breaks under 10x load? What's the single point of failure? How do you handle a database going down? Proactively identifying issues is a strong signal.
Practice system design thinking with AI mock interviews
Start my session →The 10 most common system design interview questions
1. Design a URL shortener (like bit.ly)▾
Key concepts: Hashing, storage trade-offs, redirect performance, analytics
2. Design Twitter's news feed▾
Key concepts: Fan-out on write vs. read, ranking, cache invalidation
3. Design a rate limiter▾
Key concepts: Token bucket vs sliding window, distributed counters, Redis
4. Design a notification system▾
Key concepts: Push vs pull, delivery guarantees, fan-out at scale
5. Design a file storage service (like Dropbox)▾
Key concepts: Chunking, deduplication, sync conflicts, metadata storage
6. Design a search autocomplete▾
Key concepts: Trie vs inverted index, latency requirements, personalization
7. Design a ride-sharing backend (like Uber)▾
Key concepts: Geospatial indexing, matching algorithms, real-time updates
8. Design a messaging system (like WhatsApp)▾
Key concepts: Message ordering, delivery receipts, end-to-end encryption
9. Design a video streaming platform▾
Key concepts: CDN, adaptive bitrate, chunked transfer, storage costs
10. Design an e-commerce checkout▾
Key concepts: Inventory locking, payment idempotency, order state machines
Full walkthrough: Design a URL shortener
The most common system design question. Here's how a strong candidate walks through it.
Step 1 — Clarify (say this out loud)
“Before I start — can I ask a few questions? Are we focusing on shortening, analytics, or both? What's the expected scale — 100 URLs/day or 100M? Should short URLs be random or memorable? Do they expire?”
✓ This alone signals seniority. Most beginners skip straight to drawing boxes.
Step 2 — Estimate (assume 100M URLs/day)
→ 100M URLs/day ÷ 86,400s ≈ 1,160 writes/sec
→ Assume 10:1 read/write ratio → 11,600 reads/sec
→ Each URL record ≈ 500 bytes → 100M × 500B/day = 50GB/day storage
→ 5-year retention → ~90TB total storage
These numbers tell us: read-heavy → cache aggressively. High write volume → partition writes.
Step 3 — High-level design
Write path: Client → API server → generate short code → store (longURL, shortCode, created, expires) in DB → return short URL
Read path: Client → CDN (cache hit?) → API server → Redis cache (hit?) → DB lookup → 301/302 redirect
Key decision: 301 (permanent) vs 302 (temporary) redirect. 301 = browser caches, reduces load. 302 = every redirect hits your server, enables accurate analytics. Mention this trade-off.
Step 4 — Deep dive: the hashing problem
Option A — MD5/SHA256 + truncate
Hash the long URL → take first 7 chars. Problem: hash collisions. Need to check DB on every write and retry if collision. At scale this becomes slow.
Option B — Base62 encoding of an auto-increment ID
Generate a unique ID (auto-increment or distributed ID like Snowflake) → encode in Base62 (a-z, A-Z, 0-9). 7 chars = 62^7 = 3.5 trillion combinations. No collision checking needed. ✓
Option C — Pre-generated keys (for ultra-high scale)
A Key Generation Service pre-generates random 7-char strings and stores them in a “used” and “unused” DB. Workers pull from unused. Eliminates collision risk entirely and decouples ID generation from the write path.
✓ Showing 3 options with trade-offs is what separates good from great candidates.
Step 5 — Failure modes to raise proactively
Cache stampede: what happens if a popular URL expires from cache simultaneously for 10,000 users? → Use cache-aside with jitter on TTL.
DB single point of failure: → Read replicas for the read path, primary for writes.
Hot keys: a viral URL gets 1M hits/second — Redis key for it becomes a bottleneck → local in-memory cache on app servers for top-N URLs.
Abuse: someone creates 1M URLs/second → rate limiting at API gateway, CAPTCHA on web.
Practice system design questions with AI
Start my session →What separates good from bad answers
✗ What beginners do
[Immediately starts drawing] “OK so we have a client, it calls an API, the API calls a database, we store the URL there and return the short URL. We can use Redis for caching.”
- • No clarifying questions — designing without context
- • No scale estimation — why Redis? How much data? What's the hit rate?
- • No trade-offs discussed
- • No failure modes identified
✓ What interviewers want to see
“Before I start — can I ask a few clarifying questions? [asks 3–4 questions]. Great, so we're optimising for read performance at 10M DAU. Let me do a quick back-of-envelope... [estimates QPS and storage]. OK, that tells me we're read-heavy so caching will be important and storage is a real constraint. Let me sketch the high-level components first... [draws core flow]. I'll go deeper on the hashing approach — there are a few options with different trade-offs...”
✓ Questions first, estimation drives decisions, trade-offs named, candidate leading the session
How to prepare — in order
- 1Master the framework first — Clarify → Estimate → Design → Deep Dive → Review. Internalise this. Every question, every time.
- 2Learn back-of-envelope estimation — Know: 1 day = 86,400s. 1M users × 1 request/day = ~12 QPS. 1KB × 1B records = 1TB. These come up every interview.
- 3Study 5 core building blocks deeply — Load balancer, CDN, SQL vs NoSQL trade-offs, caching strategies (cache-aside, write-through, write-behind), and message queues. Most designs use a subset of these.
- 4Practice with a real question weekly — Pick one question from the list above. Set a 45-minute timer. Walk through all 5 steps out loud. Record yourself if possible — your communication is half the score.
- 5Separate system design from behavioral prep — These are different skills. Behavioral questions are about your past decisions. System design is about your technical reasoning. Don't conflate preparation.
5 most common beginner mistakes
- 1Starting to design without clarifying requirements — the #1 mistake. The interviewer will penalise you.
- 2Choosing a technology without justifying it — 'I'll use Kafka' means nothing without explaining why.
- 3Ignoring scale — designing a URL shortener the same way whether it's 100 users or 100M users.
- 4Going too deep too early — sketch the full system before diving into any one component.
- 5Silence — system design is collaborative. Think out loud. Interviewers can't score what they can't hear.
System design is only half the SWE interview
Most engineering interviews also include a behavioral round. Once you're confident on system design, make sure your behavioral answers are as strong. See SWE behavioral question examples →
Common questions
How do I start a system design interview answer?▾
Always start by clarifying requirements. Ask: Who are the users? What's the expected scale (requests/second, data volume)? What does 'done' look like — read-heavy or write-heavy? What are the latency expectations? Interviewers reward candidates who ask smart questions before jumping to architecture. Jumping straight to drawing boxes is a common mistake.
What do interviewers actually evaluate in system design?▾
Interviewers evaluate: (1) Can you handle ambiguity by asking the right clarifying questions? (2) Can you estimate scale and use that to drive design choices? (3) Do you understand trade-offs — why you'd choose SQL over NoSQL, or cache-aside vs write-through? (4) Can you communicate your reasoning clearly? (5) Do you proactively identify failure modes? Most rejections happen because candidates design without context, not because they chose the wrong database.
Do I need to know every system design pattern to pass?▾
No. Interviewers care more about your reasoning process than encyclopedic knowledge. A candidate who clearly explains why they're making a trade-off will outperform one who name-drops Kafka and Cassandra without explaining why. Focus on: consistent hashing, caching strategies, database sharding basics, CAP theorem intuition, and how to estimate QPS and storage.
InterviewCoach AI
Practice system design and behavioral questions with AI
Reading good answers is not the same as giving them under pressure. The AI asks the question, follows up when you're vague, and scores you in real time.
Start my session →3 free sessions · No credit card