System Design ClassicWelcome to System Design Classic
The classic system design interview problems, the ones every engineer should know. Each lesson walks through a real system from requirements to architecture, explaining why each decision is made and what happens if you choose differently.
What You'll Learn
- Requirements breakdown: How to turn a vague problem into concrete functional and non-functional requirements
- Back-of-envelope estimation: Traffic, storage, and bandwidth calculations that guide design decisions
- High-level architecture: Data flow diagrams showing how components connect
- Deep dives: Critical components like caching, sharding, and consistency strategies
- Tradeoffs: Why there's no single right answer and how to reason about alternatives
Why System Design Classic?
- Interview-ready: These 15 problems cover the most commonly asked system design questions at top companies
- Pattern recognition: Each problem introduces a reusable distributed systems pattern you'll see again and again
- Full walkthroughs: Not just "draw boxes," but complete solutions with estimation, API design, storage, and scaling
- Progressive difficulty: Start with simple CRUD systems and build up to multi-service real-time architectures
Prerequisites
Complete System Design Concepts first. This course assumes you understand:
- Load balancers, caching, CDNs
- SQL vs NoSQL tradeoffs
- Message queues and async processing
- Replication, sharding, consistency models
- API design basics
Course Structure
15 problems ordered from simplest to most complex:
Warm-up (lessons 1-2): Simple CRUD systems. Pastebin, To-Do App. Focus on API design, storage choices, and basic scaling.
Fundamentals (lessons 3-8): Core interview problems. URL Shortener, Rate Limiter, Key-Value Store, Job Scheduler. Each introduces a key distributed systems pattern.
Intermediate (lessons 9-13): Multi-component systems. Notification System, News Feed, Chat, File Storage, Search. Multiple services working together with real-time requirements.
Applied (lessons 14-15): Domain-specific designs. Parking Service (IoT + geospatial), Elevator (OOD + scheduling algorithms).
How Estimation Works
In interviews, you make up the numbers, but with reasonable assumptions. The interviewer expects you to:
- State an assumption ("Let's say 500K DAU")
- Derive everything else with simple math
- Use the result to guide your design (not as decoration)
Where Do Seed Numbers Come From?
| What you need | How to get it |
|---|---|
| DAU / total users | Ask the interviewer, or assume based on product type |
| Actions per user per day | Common sense: how often do YOU use this product? |
| Read:Write ratio | Does the product involve more browsing or more creating? |
| Average object size | Estimate from contents (a tweet ~300 bytes, a photo ~2 MB) |
Anchors to Memorize
1 day = 86,400 seconds ≈ 100K (for easy mental math)
Requests → QPS:
1M requests/day ≈ 12 QPS
100M requests/day ≈ 1,200 QPS
1B requests/day ≈ 12,000 QPS
Typical DAU by product type:
Small app: 100K – 500K
Medium app: 5M – 50M
Large (FB/YT): 500M+
Peak = 3× average (rule of thumb)Estimation Formula
DAU × actions_per_user = total_actions/day
total_actions ÷ 86,400 = average QPS
average QPS × 3 = peak QPS
total_actions × size_per_action = storage/dayDirection Over Precision
The numbers tell you what kind of system you're building:
- 12 QPS → single server, keep it simple
- 1,200 QPS → still manageable, maybe add caching
- 120,000 QPS → need sharding, queues, distributed architecture
If your estimation shows 23 writes/sec, don't design for a million. If it shows 300K events/sec, don't propose a single PostgreSQL instance.
How to Use This Course
For each lesson:
- Try sketching your own design before reading (10 minutes)
- Read through the full solution
- Ask yourself: "What would break if we removed component X?"
- Take the quiz to test retention
Ready to design? Choose your first lesson from the sidebar!