System Design · Lesson 8 of 8 · Updated ·
System Design Interview Guide — Common Questions and How to Answer
This lesson turns everything into an interview plan.
1. What freshers are expected to know
For fresher / SDE-1 interviews, product companies usually ask low-level design (classes for a parking lot, an LRU cache) and only basic high-level design. Show that you understand:
- client–server, REST APIs, databases and indexes
- caching, load balancing, horizontal scaling
- SQL vs NoSQL, basic trade-offs
Experienced roles (SDE-2+) go much deeper.
2. The reusable answer template
1. Requirements functional (3–5 features) + non-functional (scale, latency, availability)
2. Estimates users → requests/sec (avg & peak), storage/year, read:write ratio
3. API 3–5 main endpoints
4. Data model main tables/collections and keys
5. High level draw: client → LB → services → cache → DB (+ queue, CDN, storage)
6. Deep dive the bottleneck: scaling the DB, caching, fan-out, consistency
7. Wrap up failures, monitoring, trade-offs, what you'd do next
3. Common questions and their key idea
| Question | The core challenge |
|---|---|
| URL shortener | unique short IDs, read-heavy caching (solved) |
| Chat app (WhatsApp) | real-time delivery, write-heavy storage (solved) |
| News feed (Instagram) | fan-out on write vs on read; celebrities with millions of followers |
| Rate limiter | token bucket / sliding window, shared counters in Redis |
| Food delivery (Swiggy) | geo search for restaurants, live location of riders, order state machine |
| Ticket booking (BookMyShow / IRCTC Tatkal) | no double-booking under huge spikes → locks/transactions, queues, holding seats with a timeout |
| Video streaming (YouTube) | upload → transcode pipeline, CDN, adaptive bitrate |
| Payment system | exactly-once effects, idempotency keys, reconciliation |
| Search autocomplete | trie / prefix index, caching popular prefixes |
4. Trade-offs interviewers love to hear
- Consistency vs availability (CAP): "likes can be eventually consistent; seat booking must be strongly consistent."
- Latency vs cost: more caching and replicas = faster but pricier.
- SQL vs NoSQL: relational integrity vs horizontal write scale.
- Push vs pull (feeds): pre-compute timelines on write (fast reads) vs build on read (cheap writes); hybrid for celebrities.
- Sync vs async: respond fast with queues, at the cost of eventual updates.
- Monolith vs microservices: simplicity now vs independent scaling later.
5. Numbers to remember
| Fact | Value |
|---|---|
| Seconds per day | 86,400 (≈ 10⁵) |
| 1 M requests/day | ≈ 12 per second |
| Redis read | ~1 ms (in-region network) |
| DB query with index | a few ms; without, can be seconds |
| Cross-continent round trip | ~100–200 ms |
6. How to prepare (4 weeks)
- Week 1: fundamentals (this subject) + Computer Networks + DBMS.
- Week 2: solve 4 classic designs on paper with the template; time yourself (35–45 min).
- Week 3: low-level design: parking lot, LRU cache, library system — class diagrams with OOP and SOLID.
- Week 4: mock interviews with a friend; practise speaking your reasoning out loud.
Common mistakes
- Silence — always think aloud.
- Over-engineering ("let's use Kafka, Kubernetes and 12 microservices") for a small problem.
- Ignoring failure cases: what if a server, cache or the database goes down?
Quick recap
- Freshers: solid basics + low-level design; experienced: deeper scaling.
- Template: requirements → estimates → API → data model → high level → deep dive → wrap up.
- Know the classic questions' core challenges and the main trade-offs.
- Practise out loud, on paper, against the clock.