System Design Interviews
The Complete Prep Guide
When you freeze in a System Design interview, it's usually not that you "don't know it" ─ it's that you "have no framework." Give yourself an hour to design Twitter and you have no idea where to even start. This post breaks it all down: a 6-step answering process, 10 must-know components, 5 classic example questions, and the 4 mistakes beginners make most.
Why System Design Is So Hard to Prep For
Compared to LeetCode, SD interviews come with 3 unique challenges:
- There's no "correct answer" ─ on the same question, different people can give designs that are all valid
- It tests "how you think," not "how much you memorized"
- You have to drive it yourself ─ the interviewer hands you a vague prompt and expects you to ask your own questions and scope it yourself
So prepping for SD isn't about "memorizing answers" ─ it's about "drilling one answer framework until it's automatic + building up a vocabulary of components."
The 6-Step Answer Framework ─ Use This Flow on Every Question
Clarify Requirements
This is the single most important step, and the one beginners are most likely to skip.
- Functional requirements: which user actions? what gets returned?
- Non-functional requirements: QPS (requests per second), number of users, data size, latency targets, availability
- scope: which features are in, which are out
Example question to ask: "Design Twitter ─ are we just doing the timeline and tweets? Or also DMs, search, and ads?"
Capacity Estimation
Do a rough back-of-the-envelope calculation to size the system.
- QPS: daily active users × average requests per person / 86400 seconds
- Storage: size per record × count × retention period
- Bandwidth: QPS × average response size
Example: 100M DAU × 50 tweets read per person = 5 billion reads / day ≈ 58K QPS.
API Design + Data Model
Sketch out the main endpoints and the data schema.
- List 3-5 core APIs
- For each API: method, path, input, output
- The main entities' fields + their relationships
Example: POST /tweets, GET /users/:id/timeline.
High-Level Design
Draw the main components and how they interact.
- Client → Load Balancer → API Gateway → Service
- Service → Cache → DB
- Service → Message Queue → Worker
- Mark the direction the data flows
At this point, draw it on paper / a whiteboard ─ don't just talk through it. The interviewer needs to see a diagram.
Deep Dive on a Single Component
The interviewer will pick 1-2 components and ask you to go deep.
- "How is the timeline generated? Fanout-on-write vs fanout-on-read?"
- "How would you design the DB schema? What's the sharding strategy?"
- "How does the cache get invalidated? How do you guarantee consistency?"
This is the part where you show the most depth. You need to be able to articulate the trade-offs.
Handle Scale + Failure
When you get asked "what if traffic is 10x?" or "what happens when the DB goes down?"
- Horizontal scale: sharding, replication
- Failure handling: retry, circuit breaker, fallback
- monitoring: metrics, alerts, SLOs
10 Must-Know Components
| Component | Purpose | When to use it |
|---|---|---|
| Load Balancer | Distributes traffic across multiple servers | QPS > what a single machine can handle |
| CDN | Caches static assets at edge nodes | Users spread across different regions |
| Cache (Redis) | Caches frequently accessed data | Read-heavy, write-light; brief inconsistency is acceptable |
| Message Queue (Kafka / RabbitMQ) | Asynchronous processing, smoothing out spikes | Time-consuming tasks that can't finish in real time |
| SQL DB (Postgres) | Structured data, strong consistency | You need transactions and complex queries |
| NoSQL (MongoDB / DynamoDB) | Unstructured data, horizontal scaling | Fast-changing schema, massive data volume |
| Search (Elasticsearch) | Full-text search | You need text tokenization and fuzzy matching |
| Object Storage (S3) | Large files (images, video) | Binary data that doesn't belong in a DB |
| API Gateway | Single entry point, auth, rate limiting | Multiple microservices that need unified management |
| Pub/Sub | Event broadcasting | Multiple downstreams need the same event |
The key thing ─ for every component, you have to be able to explain "why you chose it", not "I just use X because everyone uses it."
5 Classic Questions ─ Practice Each One Once
01 Design Twitter (Tweet + Timeline)
Core challenge: how do you generate the timeline?
- Fanout-on-write (push) ─ when I post a tweet, it's immediately written into every follower's timeline cache
- Fanout-on-read (pull) ─ when a follower opens their timeline, you query in real time for tweets from me and everyone I follow
- Hybrid: push for most users, pull for celebrities
Main components: Tweet Service, Timeline Service, User Graph, Redis (cache), Kafka (fanout).
02 Design a URL Shortener (bit.ly)
Core challenge: how do you generate a unique short code?
- Base62 encoding: turn a sequential ID into a short [a-zA-Z0-9] string
- Hash + collision handling: take the first 7 characters of md5(url), and retry on a collision
- Counter service: a central number-issuer (using Snowflake / a Ticket Server)
Main components: API, ID Generator, KV store (mapping short → long), Analytics (recording clicks).
03 Design a Chat App (WhatsApp / Slack)
Core challenge: real-time message delivery + read receipts + multi-device sync.
- WebSocket (persistent connection)
- Message broker (routes messages)
- Offline queue (re-delivers to offline users once they come back online)
Main components: WebSocket Gateway, Message Service, User Presence, Notification Service.
04 Design YouTube
Core challenge: video upload + encoding + streaming.
- Multi-resolution encoding: after upload, transcode in the background into multiple resolutions
- CDN: cache video chunks at the edge
- Adaptive bitrate (ABR): HLS / DASH switching based on connection speed
Main components: Upload Service, Encoding Workers, S3, CDN, Metadata DB.
05 Design a Rate Limiter
Core challenge: cap how many calls each user can make per second.
- Token Bucket: refill N tokens per second, reject once they're used up
- Sliding Window: precise control, but needs more computation
- Fixed Window: simple, but you get bursts at the boundaries
Main components: Redis (stores the counter), Rate Limit middleware, Config service.
The 4 Mistakes Beginners Make Most
01 Drawing Right Away Without Asking About Requirements
The interviewer says "design Twitter," and the beginner immediately starts drawing an architecture diagram.
This is the biggest thing that costs you points.
A senior engineer asks first: "Which part of Twitter? How many DAU do we need to support? Do we need search?"
That one move shows ─ you understand how important scope control is.
02 Throwing Around "Buzzwords" Without Explaining Them
A bad example:
"I'll put Kafka here, then Redis on top, sharded Postgres behind it, with nginx ingress and an Istio service mesh in front…"
The interviewer knows you've heard of these terms, but has no idea whether you understand why you'd use them.
For every technology you mention, follow it with "because ___": "I'll put Kafka here because the downstream workers are slow, so I need to decouple the producer from the consumer."
03 Only Covering the Happy Path, Never Failure
A design that only handles "everything working normally" ─ that's Junior.
A design that accounts for "what happens when X goes down" ─ that's Senior.
For every component, you should ask yourself:
- What happens if it goes down?
- Is there a fallback?
- How do you detect it?
- How do you recover?
04 Over-engineering
Designing a todo app and ending up with microservices + Kafka + 5 databases ─ the interviewer will think you don't understand trade-offs.
The principle ─ start with the simplest thing that works, and add more only when you need it.
When you get asked "what about 10x traffic?", that's when you start adding cache / shards ─ don't over-design from the start.
The Prep Period ─ A Suggested Path
Weeks 1-2: Build your component vocabulary
- For each of the 10 components above, write a note covering "what it is, when to use it, pros and cons, and alternatives"
- 30 minutes a day, until you can explain each one fluently
Weeks 3-4: Practice the 5 classic questions
- Draw each one yourself once, with no reference
- Check against public answers (Grokking, Donne Martin's system-design-primer)
- Find 5 things you didn't think of and write them into your notes
Weeks 5-6: Mock interviews
- Find a friend / a senior peer / a paid mock
- After each mock, write down "the 3 things to fix next time"
- Record yourself and listen back ─ you'll catch a lot of filler words and stumbles
Week 7: Go interview
- Interview at 1-2 companies you're not that keen on first, as a warm-up
- Then interview at the dream company
Total length ─ 7 weeks, around 50-70 hours.
The "Trap Questions" You Get Asked Often
- "Why SQL and not NoSQL?" ─ answer transactions, ACID, complex queries; don't say "I'm just more familiar with it"
- "Why Kafka and not RabbitMQ?" ─ Kafka is a log, durable + replayable; RabbitMQ is a traditional queue
- "How does the cache get invalidated?" ─ TTL, write-through, write-back, explicit invalidation ─ lay out the trade-offs
- "How do you shard the DB?" ─ by user id, by geo, by time, by hash; explain the basis for your choice
- "Consistency vs Availability?" ─ the CAP theorem, and which way your scenario leans
One Last Reminder
A System Design interview isn't testing "how many technologies you know" ─ it's testing "whether you can discuss architecture with a senior engineer."
The former you can build up within a year; the latter requires actually having built production systems.
If you haven't built anything production-grade yet ─ here's what I'd suggest:
- Pick 1 side project and take it seriously, all the way to where it can scale (add cache, add monitoring, handle failures)
- Read 1 classic book (DDIA / System Design Interview by Alex Xu)
- Read 5 big-company engineering blogs (Uber, Netflix, Discord, Cloudflare, Stripe)
Do these 3 things together, and in 3-6 months the quality of your SD answers will change completely.
Want to mock a System Design interview?
A 30-minute 1-on-1 mock interview for NT$1,500 ─ I give you the question, you answer, and I give you live feedback on "how to improve" + a full video replay.