System Design Interview Delivery 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

1. Data Model Type

   SQL vs NoSQL Decision Factors:
   - Data structure (structured/unstructured)
   - Consistency requirements
   - Scale requirements
   - Query patterns
   

2. 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

1. Load Balancer

   • Algorithm selection
   • Health checking

2. API Gateway

   • Authentication
   • Rate limiting
   • Request routing

3. Service Layer

   • Business logic
   • Service boundaries

4. 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

1. Structure is Critical

   • Follow the framework
   • Manage time effectively
   • Stay organized

2. Communication is Key

   • Explain your thinking
   • Ask clarifying questions
   • Discuss trade-offs

3. Flexibility Matters

   • Adapt to feedback
   • Consider alternatives
   • Be ready to pivot