System Design Interview Template

Use this template for any system design interview. Typical duration: 45-60 minutes.

---

1. Requirements Clarification (5 min)

Functional Requirements

Ask what the system should DO:

• What are the core features?
• Who are the users?
• What inputs/outputs are expected?

Non-Functional Requirements

Ask about quality attributes:

• Scale: How many users? Requests/sec?
• Latency: What’s acceptable response time?
• Availability: What uptime is required?
• Consistency: Strong or eventual?

Out of Scope

Explicitly clarify what NOT to design:

• “For this discussion, I’ll focus on X and Y, not Z”

---

2. Capacity Estimation (5 min)

Traffic

Users: _____ monthly active
Requests/sec: _____
Read:Write ratio: _____:1

Storage

Data per user/item: _____ bytes
Total storage: _____ TB
Growth rate: _____/month

Bandwidth

Incoming: _____ MB/s
Outgoing: _____ MB/s

---

3. High-Level Design (10 min)

Draw the main components:

[Client] --> [Load Balancer] --> [App Servers]
                                      |
                    +-----------------+-----------------+
                    |                 |                 |
               [Cache]           [Database]       [Storage]

List core components:

1. Clients - Web, Mobile, API
2. Load Balancer - Traffic distribution
3. Application Servers - Business logic
4. Database - Persistent storage
5. Cache - Speed optimization
6. CDN - Static content

---

4. API Design (5 min)

Define key APIs:

REST Example

POST /api/v1/resource
GET  /api/v1/resource/{id}
PUT  /api/v1/resource/{id}
DELETE /api/v1/resource/{id}

Request/Response

// Request
{
  "field1": "value",
  "field2": 123
}

// Response
{
  "id": "abc123",
  "created_at": "2024-01-01T00:00:00Z"
}

---

5. Data Model (5 min)

Schema Design

CREATE TABLE users (
    id UUID PRIMARY KEY,
    email VARCHAR(255) UNIQUE,
    created_at TIMESTAMP
);

CREATE TABLE items (
    id UUID PRIMARY KEY,
    user_id UUID REFERENCES users(id),
    data JSONB,
    created_at TIMESTAMP
);

Database Choice

• SQL - ACID, relations, complex queries
• NoSQL - Scale, flexibility, simple access patterns

---

6. Deep Dive Components (15 min)

Pick 2-3 components to dive deep:

Scaling Strategy

• Horizontal vs Vertical
• Stateless services
• Database sharding

Caching Strategy

• What to cache?
• Cache invalidation?
• TTL policies?

Data Partitioning

• Partition key selection
• Consistent hashing
• Replication factor

Failure Handling

• Retry policies
• Circuit breaker
• Graceful degradation

---

7. Trade-offs & Alternatives (5 min)

Discuss decisions made:

Decision	Pros	Cons
SQL vs NoSQL	ACID	Scale limits
Push vs Pull	Real-time	Connection overhead
Strong vs Eventual	Accuracy	Latency

---

8. Monitoring & Operations (if time)

• Metrics to track
• Alerting thresholds
• Deployment strategy
• Disaster recovery

---

Quick Cheat Sheet

Numbers to Know

• L1 cache: 0.5 ns
• RAM: 100 ns
• SSD: 100 μs
• HDD: 10 ms
• Network (datacenter): 0.5 ms
• Network (cross-continent): 150 ms

Capacity

• 1 server: 10K-100K req/sec (depends on work)
• 1 MySQL: 10K queries/sec
• 1 Redis: 100K ops/sec

Storage

• 1 char = 1-4 bytes (UTF-8)
• 1 int = 4 bytes
• 1 UUID = 36 chars or 16 bytes binary

---

Common Patterns

1. Rate Limiting - Token bucket, sliding window
2. Load Balancing - Round robin, least connections
3. Caching - Write-through, write-behind, write-around
4. Sharding - Range, hash, directory
5. Replication - Master-slave, multi-master
6. Message Queue - Decouple producers/consumers
7. CDN - Edge caching for static content