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

System Design Interview Delivery Framework

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