What is High Level Design?
Twitter processes 500 million tweets per day. Netflix serves 232 million subscribers across 190 countries. How do you even begin to design systems that operate at this scale?
That's exactly what High Level Design teaches you.
HIGH LEVEL DESIGN
- System architecture
- Component interactions
- Data flow between services
- Scaling strategies
- Technology choices
LOW LEVEL DESIGN
- Class structures
- Method signatures
- Design patterns
- Object relationships
- Code organization
The System Design Iceberg
Think of system design like an iceberg. HLD is what's visible above water - the architecture that everyone can see and discuss. LLD is below the surface - the implementation details that make it work.
Requirements: The Foundation
Before designing anything, you need to understand what you're building and how big it needs to be.
Functional Requirements (What)
These define what the system does:
- Users can post messages
- Users can follow other users
- Users can see a feed of posts from people they follow
Non-Functional Requirements (How)
These define how the system performs:
Response time < 200ms
10K requests/second
99.99% uptime
Data accuracy guarantees
The Architect's Framework
When you're faced with any system design problem, follow this framework:
1. Clarify Requirements
Never assume. Ask questions like:- What are the core features we need to support?
- How many users are we designing for?
- What's more important: consistency or availability?
- Are there any specific latency requirements?
2. Estimate Scale
Back-of-the-envelope calculations help you understand the magnitude:
Example: Twitter-like system
Daily Active Users: 200 million
Tweets per user/day: 2
Total tweets/day: 400 million
Tweets per second: 400M / 86400 ≈ 4,600 TPS
Read:Write ratio: 100:1
Reads per second: 460,000 RPS3. Design the Architecture
Sketch the major components and how they interact:
- What services do we need?
- How do they communicate?
- Where does data live?
- How does data flow through the system?
4. Deep-Dive
Pick critical areas to explore in detail:
- Database schema design
- Caching strategy
- How to handle failures
- Scaling bottlenecks
Real-World Example: Twitter's Journey
Twitter didn't start as a massive distributed system. In 2006, it was a simple Ruby on Rails app with a single MySQL database.
Twitter became famous for its "Fail Whale" error page. The simple architecture couldn't handle viral moments. A single celebrity tweet could bring down the entire site.
Twitter migrated to a distributed architecture with "hundreds of thousands of servers" across multiple data centers on five continents. They went from constant outages to handling World Cup traffic spikes without breaking a sweat.
What You'll Learn in This Course
Vertical vs horizontal, stateless design
Distribute traffic efficiently
Speed up reads dramatically
Sharding, replication, consistency
Async processing at scale
Real designs from tech giants
Key Takeaways
- HLD = 30,000 foot view - System architecture, not code details
- Requirements first - Functional (what) + Non-functional (how)
- Framework matters - Clarify → Estimate → Design → Deep-dive
- Start simple, then scale - Twitter started with one server too
Next up: Scaling Basics - Understanding vertical vs horizontal scaling and when to use each.