Lesson 128 of 129
System Design Study Plan
This plan orders the course material into four weeks. It assumes roughly 10 hours per week; with less time, extend the plan over more weeks and keep the same order, and treat each week's "Also read" list as optional. The order goes from vocabulary and estimation, to storage and caching, to distributed systems and messaging, to full problems. Each week ends with a practice session on a full design problem.
flowchart LR
W1["Week 1: Foundations, networking, storage"] --> W2["Week 2: Caching, distributed theory, messaging"]
W2 --> W3["Week 3: Classic problems and resilience"]
W3 --> W4["Week 4: Advanced problems and mock interviews"]Week 1: Foundations, networking, and storage
Goal: learn the interview format, the framework, estimation, and the core building blocks.
| Day | Topics |
|---|---|
| 1 | What is the system design interview, system design interview framework |
| 2 | Requirements, back-of-envelope estimation |
| 3 | Scalability, availability, reliability, load balancing |
| 4 | DNS, TCP and UDP, HTTP versions, REST API design |
| 5 | SQL vs NoSQL, ACID and isolation, database indexing |
| 6 | Database replication, sharding, consistent hashing |
| 7 | Practice: design a URL shortener using the framework, timed at 45 minutes |
Also read this week if time allows: reverse proxy and API gateway, content delivery networks, key-value and document stores.
Week 2: Caching, distributed systems theory, and messaging
Goal: understand consistency, failure, and asynchronous communication.
Also read: storage engines: B-tree vs LSM, leader election, time, clocks, and ordering, probabilistic data structures.
Week 3: Classic problems and resilience
Goal: apply building blocks to complete problems, and add failure handling.
| Day | Topics |
|---|---|
| 1 | Timeouts, retries, backoff, jitter, circuit breaker |
| 2 | Rate limiting algorithms, observability |
| 3 | Design a key-value store, design a unique ID generator |
| 4 | Design a notification system, design a chat system |
| 5 | Design a web crawler, design search autocomplete |
| 6 | Design YouTube, design Google Drive |
| 7 | Practice: two full mock designs from the classic list, no notes, 45 minutes each |
Also read: multi-region and disaster recovery, authentication, OAuth2, JWT, design Google Maps, design a proximity service, design a distributed message queue.
Week 4: Advanced problems and mock interviews
Goal: handle problems with strict correctness or extreme scale, and rehearse under time limits.
| Day | Topics |
|---|---|
| 1 | Distributed transactions: 2PC and 3PC, saga pattern, transactional outbox and CDC |
| 2 | Design a payment system, design a digital wallet |
| 3 | Design ticket booking, design hotel reservation |
| 4 | Design Uber, design a stock exchange |
| 5 | Design ad click aggregation, design a metrics monitoring system |
| 6 | Design Twitter, design WhatsApp, design a leaderboard |
| 7 | Full mock interview with another person, then review using the interview checklist |
Also read: CRDTs, geospatial indexing, design Google Docs, design a job scheduler, design a search engine, design a distributed cache.
Optional: microservices track
For roles involving microservices, read in this order: monolith to microservices, when to use microservices, domain-driven design and bounded contexts, database per service, choreography vs orchestration, event sourcing and CQRS, service mesh and sidecars, and the e-commerce microservices design.
Why this order
| Stage | Reason it comes before the next |
|---|---|
| Foundations and estimation | Every problem uses the framework and the numbers to justify choices. |
| Storage, replication, sharding | Almost every design has a database whose scaling limits drive the rest of the design. |
| Caching | Depends on storage latency and consistency concepts. |
| Distributed theory | Explains the guarantees that replication, caches, and queues can and cannot give. |
| Messaging | Asynchronous processing appears in most fan-out and pipeline problems. |
| Resilience | Applied in the deep-dive and wrap-up phases of every problem. |
| Full problems | Combine the previous stages, so gaps show up as missing components. |
Practice method
For each problem:
- Attempt cold. Set a timer for 45 minutes. Work through requirements, estimation, high-level design, and deep dive on paper or a drawing tool, speaking aloud.
- Record. Keep the requirements list, numbers, diagram, and the trade-offs stated.
- Compare. Read the course article. Note components, estimates, and trade-offs that were missing.
- Repeat the gaps. For each gap, read the linked concept article and write a two-sentence summary of the mechanism.
- Redo later. Repeat the same problem after several days, at the same time limit.
Practice with another person when possible. A partner asks clarifying questions and challenges decisions, which trains explanation under pressure.
Problem checklist
After each problem, confirm the design covers:
- Functional requirements with priorities and non-goals.
- Non-functional targets: latency, availability, consistency, durability, scale.
- Estimates: QPS (average and peak), storage, bandwidth, memory.
- API with request and response shapes.
- Data model and the reason for the storage choice.
- Architecture diagram with write path and read path.
- At least two deep dives with alternatives and trade-offs.
- Failure handling: what happens when each component fails or slows.
- Bottlenecks, hot spots, and single points of failure.
- Monitoring and alerting.
- Extensions: multi-region, new features, higher scale.
Tracking progress
| Skill | Signal of readiness |
|---|---|
| Estimation | Computes QPS, storage, and bandwidth in under five minutes. |
| Building blocks | Explains how each component works, not only what it is. |
| Trade-offs | Names an alternative and a cost for each major choice. |
| Time management | Completes all four steps within the limit. |
| Depth | Handles follow-up questions on partitioning, consistency, and failures. |
Interview questions
- In what order should topics be studied? Foundations and estimation first, then storage and caching, then distributed systems theory and messaging, then full problems. Problems reuse the concepts, so concepts studied first make problems faster to learn.
- How many problems should be practiced? Enough that the same building blocks appear repeatedly in different combinations. Repeated, timed practice on a smaller set of varied problems (for example a mix of storage, messaging, real-time, and transactional problems) covers more building blocks than a single pass over many problems.
- Why redo a problem after reading the solution? Reading a solution does not test recall or explanation. Redoing the problem from the requirements shows which parts were understood.