Day 28 — System Design 101
For 27 days you’ve answered the question “can you write the algorithm?” System design asks a different one: “can you assemble a system out of algorithms, data structures, and machines — and defend every trade-off you made?”
There’s no single right answer. There’s no return statement. The interviewer hands you a deliberately vague prompt — “design Twitter” — and watches how you think: Do you nail down requirements before drawing boxes? Do you estimate scale before picking a database? Do you know why you’d reach for a cache, and what breaks when you do?
This chapter is the bridge from “I can solve LeetCode” to “I can design a system on a whiteboard without freezing.” It’s light on math and heavy on trade-offs — because that’s exactly what the interview rewards.
What you’ll learn today
- The interview framework — a repeatable 6-step script (requirements → estimation → API → data model → high-level design → deep dives) so you never stare at a blank whiteboard again
- Back-of-the-envelope estimation — turning “design YouTube” into concrete QPS, storage, and bandwidth numbers in two minutes
- The building blocks — load balancers, caches, CDNs, message queues, blob storage, SQL vs NoSQL — what each one is, when to reach for it, and what it costs you
- Scaling & trade-offs — vertical vs horizontal, replication, sharding, consistent hashing, the CAP theorem, and consistency models
- A fully worked case study — scaling a URL shortener from 10 users to 100 million, decision by decision
- Low-level design — the OOP-flavored design interview: SOLID, the must-know patterns, and a worked parking-lot class design
- Eight classic design questions — rate limiter, TinyURL, typeahead, news feed, chat, key-value store, web crawler, notification service
System design interviews don’t have a “right” answer — they have a “well-defended” answer. Two candidates can propose completely different architectures and both pass, if each one justified their choices against the requirements and named the trade-offs. The skill being tested is structured reasoning under ambiguity, not memorized architectures. This chapter teaches the structure.
Roadmap
- Introduction — what system design is, why interviews are open-ended, the vocabulary (latency vs throughput, availability, scalability), and the mental model.
- The Framework — the 6-step script, plus back-of-the-envelope estimation with an interactive calculator.
- Building Blocks — load balancers, caching, CDNs, databases (SQL vs NoSQL), message queues, blob storage — the Lego bricks every design is built from.
- Scaling & Trade-offs — vertical vs horizontal scaling, replication, sharding, consistent hashing, and the CAP theorem with an interactive triangle.
- Case Study — URL Shortener — the full 6-step framework applied end-to-end, from requirements to deep dives.
- Low-Level Design (LLD) — the other design interview: object-oriented class design, SOLID, the patterns worth knowing, and a worked parking-lot example.
- Basic Questions — concept checks: latency ladders, cache invalidation, why you shard, how DNS fits in.
- Practice Questions — eight interview classics, each worked through the framework.
You will not memorize your way through a system design interview. Memorizing “the Twitter architecture” fails the moment the interviewer changes one constraint (“now make it work offline”). What transfers is the process — the questions you ask, the order you ask them in, and the trade-offs you weigh. Internalize the framework, and any prompt becomes fill-in-the-blanks.
This is Day 28 — the first of the synthesis days. Tomorrow, Day 29 — Mock Interview puts the coding and the design skills together under time pressure; Day 30 — Victory Lap ties the whole 30-day arc into a single map.