System Design Interview Framework (High Level Design)
Golden Rule
Never start drawing architecture immediately. First understand the problem. A senior engineer spends the first few minutes understanding the requirements, not drawing Kafka or Redis.
Never start drawing architecture immediately. First understand the problem. A senior engineer spends the first few minutes understanding the requirements, not drawing Kafka or Redis.
Step 1 - Understand Requirements
Functional Requirements
Ask:
- What problem are we solving?
- Who are the users?
- What are the core features?
Why?
If you don't understand the business problem, you'll design the wrong system.
Non Functional Requirements
| Question | Why Ask? | If You Don't Ask... |
|---|---|---|
| Daily Active Users? | Understand system size. | You won't know whether one server is enough or hundreds are needed. |
| Peak Throughput / QPS? | Helps decide Load Balancer, Kafka, Caching, Database Scaling. | You may design a system that works for 100 users but crashes at 1 million. |
| Read Heavy or Write Heavy? | Decides Cache strategy and Database design. | You may unnecessarily optimize writes while reads are the real bottleneck. |
| Latency Requirement? | Decides whether cache is needed. | You may use only database and response becomes slow. |
| Consistency Requirement? | Decides SQL vs NoSQL and locking strategy. | You may lose bookings or create duplicate records. |
| Single Region or Global? | Decides CDN, Replication, Geo Distribution. | Your system may work only in one country. |
Step 2 - Design APIs
APIs define how clients communicate with the system.
GET /search POST /booking POST /payment DELETE /booking
Why?
APIs define the contract between frontend and backend.
Step 3 - Draw High Level Architecture
Client ↓ Load Balancer ↓ API Gateway ↓ Booking Service Inventory Service Payment Service ↓ Database
Why?
First identify major components.
Don't discuss implementation yet.
Step 4 - Explain Data Flow
User ↓ Search Hotel ↓ Inventory Check ↓ Booking ↓ Payment ↓ Kafka Event ↓ Notification
Why?
Interviewers care more about the flow than the boxes.
Step 5 - Data Storage
| Component | Technology | Reason |
|---|---|---|
| Booking | PostgreSQL | ACID Transactions |
| Search | Elasticsearch | Fast Search |
| Cache | Redis | Reduce Database Load |
Step 6 - Scaling
- Load Balancer
- Horizontal Scaling
- Read Replica
- Sharding
- Kafka
- CDN
Why?
Show how the system handles millions of users.
Step 7 - Failure Handling
Always think:
- What if Payment fails?
- What if Database crashes?
- What if Kafka is down?
- What if Redis fails?
- Duplicate Request?
Possible Solutions:
- Retry
- Circuit Breaker
- Saga
- Outbox
- Idempotency
Step 8 - Trade-offs
Explain WHY you selected each technology.
- Why SQL?
- Why Redis?
- Why Kafka?
- Why Elasticsearch?
A senior engineer never says
"Because everyone uses Redis."
They explain the engineering trade-off.
Required
Intermediate Free
System design guide
Previous: None
Next: None