System Design Interview Delivery Framework
Introduction•
Learn a structured approach to tackle system design interviews effectively with a proven step-by-step framework.
Framework Overview
Time Management Overview
Requirements Gathering ~5 minutes
API Design ~2 minutes
Database Design ~2 minutes
High-Level Design ~15 minutes
Deep Dives ~15 minutes
Future Improvements ~5 minutes
1. Requirements Gathering (5 minutes)
Functional Requirements
- Start with "Users should be able to..."
- Focus on top 3 core features
- Use targeted questions:
"Does the system need to support feature X?" "What happens if condition Y occurs?" "Should users be able to do Z?"
Non-Functional Requirements
Focus on top 3-5 requirements:
1. Availability & Reliability
- Define uptime requirements (e.g., 99.99%)
- Specify fault tolerance needs
2. Performance
- API latency targets (e.g., p95 < 500ms)
- Throughput requirements
3. Scalability
- Target user base (e.g., 100M+ DAU)
- Growth projections
4. Security
- Data protection requirements
- Access control needs
- Compliance requirements
5. Extensibility
- Future feature considerations
- Integration requirements
Capacity Estimation (Optional)
Only if relevant to core design decisions:
Daily Active Users (DAU) → Transactions per Second (TPS)
DAU * Actions per User / Seconds per Day = TPS
Example: 1M users * 10 actions / 86400 seconds ≈ 116 TPS
2. API Design (2 minutes)
RESTful API Examples
# Resource Creation
POST /v1/resources
Request Body:
{
"name": string,
"type": string,
"attributes": object
}
Response: 201 Created
{
"id": string,
"name": string,
"type": string,
"attributes": object,
"created_at": timestamp
}
# Resource Retrieval
GET /v1/resources/:resourceId
Response: 200 OK
{
"id": string,
"name": string,
"type": string,
"attributes": object,
"created_at": timestamp,
"updated_at": timestamp
}
# Resource Update
PUT /v1/resources/:resourceId
Request Body:
{
"name": string,
"attributes": object
}
Response: 200 OK
{
"id": string,
"name": string,
"type": string,
"attributes": object,
"updated_at": timestamp
}
# Resource Deletion
DELETE /v1/resources/:resourceId
Response: 204 No Content
# List Resources with Pagination
GET /v1/resources?limit=20&cursor=xyz
Response: 200 OK
{
"items": [
{
"id": string,
"name": string,
"type": string
}
],
"next_cursor": string
}
# Batch Operations
POST /v1/resources/batch
Request Body:
{
"resources": [
{
"name": string,
"type": string
}
]
}
Response: 200 OK
{
"successful": [
{
"id": string,
"name": string
}
],
"failed": [
{
"index": number,
"error": string
}
]
}
Error Response Format
400 Bad Request
{
"error": {
"code": "INVALID_REQUEST",
"message": "Invalid resource type provided",
"details": {
"field": "type",
"reason": "must be one of [A, B, C]"
}
}
}
404 Not Found
{
"error": {
"code": "RESOURCE_NOT_FOUND",
"message": "Resource with ID 'xyz' not found"
}
}
Security Considerations
# Request Headers
Authorization: Bearer ${jwt_token}
Content-Type: application/json
X-Request-ID: ${uuid} # for request tracing
X-API-Version: 2024-02-20 # API version date
# Rate Limiting Headers
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 95
X-RateLimit-Reset: 1519296060
3. Database Design (2 minutes)
Key Considerations
-
Data Model Type
SQL vs NoSQL Decision Factors: - Data structure (structured/unstructured) - Consistency requirements - Scale requirements - Query patterns
-
Schema Design
-- SQL Example CREATE TABLE resources ( id UUID PRIMARY KEY, user_id UUID REFERENCES users(id), created_at TIMESTAMP, updated_at TIMESTAMP, INDEX idx_user_id (user_id) );
// NoSQL Example { "PK": "USER#123", "SK": "RESOURCE#456", "data": {}, "GSI1PK": "TYPE#resource", "GSI1SK": "DATE#2024-02-20" }
4. High-Level Design (15 minutes)
Component Architecture
Client → Load Balancer → API Gateway → Services → Data Layer
↓
Cache Layer
Key Components
-
Load Balancer
- Algorithm selection
- Health checking
-
API Gateway
- Authentication
- Rate limiting
- Request routing
-
Service Layer
- Business logic
- Service boundaries
-
Data Layer
- Primary storage
- Caching strategy
- Data partitioning
5. Deep Dives (15 minutes)
Scalability
1. Horizontal Scaling
- Stateless services
- Database sharding
- Cache distribution
2. Performance Optimization
- Caching strategies
- Read/Write patterns
- Data denormalization
Failure Handling
1. Service Failures
- Circuit breakers
- Fallback mechanisms
- Retry policies
2. Data Failures
- Replication
- Backup strategies
- Recovery procedures
Best Practices
Do's
- Start with simple design
- Focus on core requirements
- Be proactive about trade-offs
- Use real numbers when possible
Don'ts
- Over-optimize prematurely
- Skip clarifying questions
- Ignore non-functional requirements
- Get stuck on minor details
Key Takeaways
-
Structure is Critical
- Follow the framework
- Manage time effectively
- Stay organized
-
Communication is Key
- Explain your thinking
- Ask clarifying questions
- Discuss trade-offs
-
Flexibility Matters
- Adapt to feedback
- Consider alternatives
- Be ready to pivot