Design Google Drive

A cloud file storage and synchronization service that allows users to store files, sync across devices, share with others, and collaborate in real-time.

1. Requirements Clarification

“Before diving into the design, let me clarify the requirements to make sure I understand the scope correctly.”

Functional Requirements

Non-Functional Requirements

Out of Scope

• Real-time collaborative editing (Google Docs - separate system)
• Media streaming
• Advanced search with content indexing

Interview tip: Always clarify scope. Google Drive is complex - focusing on core storage and sync is appropriate for a 45-minute interview.

2. Back of Envelope Estimation

“Let me estimate the scale to inform our design decisions.”

User Scale

Traffic Estimation

Storage Estimation

Bandwidth Estimation

Key insight: The sync check QPS (115K) is much higher than upload/download. We need to optimize sync operations heavily.

3. High-Level Design

“Let me start with the high-level architecture and then we can dive into specific components.”

System Architecture

flowchart TB
    subgraph Clients["Client Devices"]
        WEB[Web Browser]
        DESKTOP[Desktop Client]
        MOBILE[Mobile App]
    end

    subgraph Edge["Edge Layer"]
        CDN[CDN]
        LB[Load Balancer]
    end

    subgraph API["API Layer"]
        APIGW[API Gateway]
        AUTH[Auth Service]
    end

    subgraph Services["Core Services"]
        META[Metadata Service]
        UPLOAD[Upload Service]
        DOWNLOAD[Download Service]
        SYNC[Sync Service]
        SHARE[Sharing Service]
        NOTIFY[Notification Service]
    end

    subgraph Storage["Storage Layer"]
        METADB[(Metadata DB)]
        BLOCKSTORE[Block Storage]
        CACHE[(Redis Cache)]
        MQ[Message Queue]
    end

    WEB --> CDN
    DESKTOP --> LB
    MOBILE --> LB
    CDN --> LB
    LB --> APIGW
    APIGW --> AUTH
    APIGW --> META
    APIGW --> UPLOAD
    APIGW --> DOWNLOAD
    APIGW --> SYNC
    APIGW --> SHARE

    META --> METADB
    META --> CACHE
    UPLOAD --> BLOCKSTORE
    UPLOAD --> MQ
    DOWNLOAD --> BLOCKSTORE
    DOWNLOAD --> CDN
    SYNC --> CACHE
    SYNC --> MQ
    SHARE --> METADB
    NOTIFY --> MQ

Core APIs

Upload File

POST /api/v1/files/upload
Headers:
  Authorization: Bearer <token>
  Content-Type: multipart/form-data
  X-Upload-Id: <resumable-upload-id>  // For resumable uploads
Body:
  - file: binary
  - parent_folder_id: string
  - filename: string
Response:
  {
    "file_id": "f_abc123",
    "name": "document.pdf",
    "size": 1048576,
    "checksum": "sha256:abc...",
    "created_at": "2024-01-15T10:30:00Z",
    "version": 1
  }

Download File

GET /api/v1/files/{file_id}/download
GET /api/v1/files/{file_id}/download?version=3  // Specific version
Headers:
  Authorization: Bearer <token>
Response:
  - 302 Redirect to signed CDN URL (for large files)
  - 200 with file content (for small files)

Sync Changes

POST /api/v1/sync
Headers:
  Authorization: Bearer <token>
Body:
  {
    "device_id": "device_123",
    "last_sync_cursor": "cursor_abc",
    "local_changes": [
      {
        "path": "/docs/file.txt",
        "checksum": "sha256:...",
        "modified_at": "2024-01-15T10:30:00Z",
        "action": "modify"
      }
    ]
  }
Response:
  {
    "server_changes": [...],
    "conflicts": [...],
    "new_cursor": "cursor_def"
  }

Share File

POST /api/v1/files/{file_id}/share
Headers:
  Authorization: Bearer <token>
Body:
  {
    "recipients": [
      {"email": "user@example.com", "role": "editor"},
      {"email": "other@example.com", "role": "viewer"}
    ],
    "link_settings": {
      "enabled": true,
      "access": "anyone_with_link",
      "role": "viewer",
      "expiry": "2024-02-15T00:00:00Z"
    }
  }

4. Deep Dive

4.1 File Upload Flow

“Let me walk through the upload flow, which is one of the most critical paths.”

Why Chunked Upload?

Decision: Chunked upload with 4MB chunks for reliability and parallelism.

Upload Flow

sequenceDiagram
    participant C as Client
    participant API as API Gateway
    participant US as Upload Service
    participant BS as Block Storage
    participant MS as Metadata Service
    participant MQ as Message Queue

    C->>API: POST /upload/init (filename, size, checksum)
    API->>US: Initialize upload
    US->>MS: Create pending file record
    MS-->>US: file_id
    US-->>C: upload_id, chunk_urls[]

    par Parallel chunk uploads
        C->>BS: PUT chunk_1 (presigned URL)
        C->>BS: PUT chunk_2 (presigned URL)
        C->>BS: PUT chunk_3 (presigned URL)
    end

    C->>API: POST /upload/complete (upload_id, chunk_checksums)
    API->>US: Finalize upload
    US->>BS: Verify all chunks
    US->>MS: Update file status to 'active'
    US->>MQ: Publish FileUploaded event
    US-->>C: Success (file metadata)

Block-Level Deduplication

“To save storage, we deduplicate at the block level, not file level.”

flowchart LR
    subgraph Client["Client Side"]
        FILE[File] --> CHUNK[Split into 4MB chunks]
        CHUNK --> HASH[Calculate SHA-256 per chunk]
    end

    subgraph Server["Server Side"]
        HASH --> CHECK{Block exists?}
        CHECK -->|Yes| SKIP[Skip upload, reference existing]
        CHECK -->|No| UPLOAD[Upload block]
        UPLOAD --> STORE[(Block Storage)]
        SKIP --> META[Update metadata]
        STORE --> META
    end

Deduplication benefits:

• Same file uploaded by different users → stored once
• Modified file → only changed blocks uploaded
• Backup copies → nearly free

Example:

File A: [Block1][Block2][Block3][Block4]
File B: [Block1][Block2][Block5][Block4]  // Modified file
Storage: Only 5 unique blocks stored, not 8

4.2 Sync Service

“Sync is the most challenging part. We need to handle multiple devices editing the same file.”

Sync Strategies Comparison

Decision: WebSocket for real-time notifications + Delta sync for efficient transfers.

Sync Architecture

flowchart TB
    subgraph Devices["User Devices"]
        D1[Desktop]
        D2[Laptop]
        D3[Phone]
    end

    subgraph Sync["Sync Infrastructure"]
        WSS[WebSocket Servers]
        SS[Sync Service]
        subgraph State["State Management"]
            REDIS[(Redis)]
            CURSOR[Cursor Store]
        end
    end

    subgraph Storage["Storage"]
        META[(Metadata DB)]
        BLOCKS[(Block Storage)]
    end

    D1 <-->|WebSocket| WSS
    D2 <-->|WebSocket| WSS
    D3 <-->|WebSocket| WSS

    WSS --> SS
    SS --> REDIS
    SS --> CURSOR
    SS --> META
    SS --> BLOCKS

Cursor-Based Sync

Each device maintains a cursor (checkpoint) of its last sync position:

{
  "device_id": "desktop_123",
  "user_id": "user_456",
  "cursor": "1705312200_seq_99847",
  "last_sync": "2024-01-15T10:30:00Z"
}

Sync flow:

1. Device sends current cursor
2. Server returns all changes since cursor
3. Device applies changes, updates local cursor
4. If conflicts, return conflict list for resolution

Conflict Resolution

“What happens when two devices edit the same file offline?”

stateDiagram-v2
    [*] --> Detecting: Changes received
    Detecting --> NoConflict: Timestamps don't overlap
    Detecting --> Conflict: Same file modified

    NoConflict --> Apply: Apply changes
    Apply --> [*]

    Conflict --> Strategy: Determine resolution
    Strategy --> LastWriteWins: Non-critical files
    Strategy --> CreateCopy: Important files
    Strategy --> UserChoice: Manual resolution

    LastWriteWins --> Apply
    CreateCopy --> Apply
    UserChoice --> UserInput
    UserInput --> Apply

Conflict strategies:

4.3 Metadata Service

“Metadata operations are read-heavy. Let’s design the data model.”

Data Model

erDiagram
    USER ||--o{ FILE : owns
    USER ||--o{ DEVICE : has
    FILE ||--o{ FILE_VERSION : has
    FILE ||--o{ FILE_BLOCK : contains
    FILE ||--o{ SHARING : shared_via
    FOLDER ||--o{ FILE : contains
    FOLDER ||--o{ FOLDER : contains

    USER {
        string user_id PK
        string email
        string name
        bigint storage_quota
        bigint storage_used
        timestamp created_at
    }

    FILE {
        string file_id PK
        string user_id FK
        string folder_id FK
        string name
        bigint size
        string checksum
        int current_version
        string status
        timestamp created_at
        timestamp modified_at
    }

    FILE_VERSION {
        string version_id PK
        string file_id FK
        int version_number
        bigint size
        string checksum
        string modified_by
        timestamp created_at
    }

    FILE_BLOCK {
        string block_id PK
        string file_id FK
        int version_number
        int block_index
        string block_hash
        bigint block_size
    }

    FOLDER {
        string folder_id PK
        string user_id FK
        string parent_id FK
        string name
        timestamp created_at
    }

    DEVICE {
        string device_id PK
        string user_id FK
        string device_name
        string device_type
        string sync_cursor
        timestamp last_sync
    }

    SHARING {
        string share_id PK
        string file_id FK
        string shared_with
        string role
        string share_type
        timestamp expires_at
    }

Database Choice

Sharding strategy: Shard by user_id to keep all user’s files on same shard.

Caching Strategy

flowchart LR
    subgraph Read["Read Path"]
        REQ[Request] --> L1[L1: Local Cache]
        L1 -->|Miss| L2[L2: Redis Cluster]
        L2 -->|Miss| DB[(PostgreSQL)]
        DB --> L2
        L2 --> L1
    end

    subgraph Invalidation["Cache Invalidation"]
        WRITE[Write] --> DB2[(PostgreSQL)]
        DB2 --> PUB[Pub/Sub]
        PUB --> INV1[Invalidate L2]
        PUB --> INV2[Invalidate L1s]
    end

Cache policies:

4.4 Block Storage

“Let’s discuss how we store the actual file content.”

Storage Architecture

flowchart TB
    subgraph Upload["Upload Path"]
        CLIENT[Client] --> UPLOAD[Upload Service]
        UPLOAD --> DEDUP{Deduplicate}
        DEDUP -->|New block| ENCRYPT[Encrypt]
        DEDUP -->|Exists| REF[Reference existing]
        ENCRYPT --> COMPRESS[Compress]
        COMPRESS --> STORE[Store]
    end

    subgraph Storage["Storage Tiers"]
        STORE --> HOT[Hot: SSD]
        HOT -->|After 30 days| WARM[Warm: HDD]
        WARM -->|After 90 days| COLD[Cold: Glacier]
    end

    subgraph Durability["Durability"]
        HOT --> REP1[Replica 1]
        HOT --> REP2[Replica 2]
        HOT --> REP3[Replica 3]
    end

Storage Tiers

Block Storage Schema

Block Storage Layout:
/blocks/
  /{hash_prefix}/        # First 2 chars of hash (256 buckets)
    /{block_hash}        # Full SHA-256 hash
      - data             # Encrypted, compressed block
      - metadata.json    # Size, references, created_at

Example:

/blocks/a7/a7b3c4d5e6f7...
  - data: [encrypted binary]
  - metadata.json: {
      "size": 4194304,
      "compressed_size": 3145728,
      "reference_count": 47,
      "created_at": "2024-01-15T10:30:00Z"
    }

4.5 Sharing Service

“Sharing is more complex than it appears. We need to handle permissions, links, and notifications.”

Permission Model

flowchart TB
    subgraph Permissions["Permission Hierarchy"]
        OWNER[Owner] --> EDITOR[Editor]
        EDITOR --> COMMENTER[Commenter]
        COMMENTER --> VIEWER[Viewer]
    end

    subgraph Capabilities["Capabilities"]
        OWNER --> |Can| O1[Delete]
        OWNER --> |Can| O2[Share]
        OWNER --> |Can| O3[Transfer ownership]
        EDITOR --> |Can| E1[Edit]
        EDITOR --> |Can| E2[Add files]
        COMMENTER --> |Can| C1[Comment]
        VIEWER --> |Can| V1[View]
        VIEWER --> |Can| V2[Download]
    end

Share Types

Sharing Flow

sequenceDiagram
    participant U1 as Owner
    participant API as API Gateway
    participant SS as Sharing Service
    participant MS as Metadata Service
    participant NS as Notification Service
    participant U2 as Recipient

    U1->>API: Share file with user@example.com
    API->>SS: Create share
    SS->>MS: Verify file ownership
    MS-->>SS: Confirmed
    SS->>SS: Create sharing record
    SS->>NS: Send notification
    NS->>U2: Email: "File shared with you"
    SS-->>U1: Share successful

    U2->>API: Access shared file
    API->>SS: Check permissions
    SS-->>API: Viewer access granted
    API-->>U2: File content

4.6 Notification Service

“Users need to know when files change. Let’s design real-time notifications.”

Notification Architecture

flowchart TB
    subgraph Events["Event Sources"]
        UPLOAD[File Upload]
        EDIT[File Edit]
        SHARE[File Shared]
        COMMENT[Comment Added]
    end

    subgraph Processing["Event Processing"]
        MQ[Message Queue]
        PROCESSOR[Notification Processor]
        ROUTER[Recipient Router]
    end

    subgraph Delivery["Delivery Channels"]
        PUSH[Push Notification]
        EMAIL[Email]
        WS[WebSocket]
        INAPP[In-App]
    end

    UPLOAD --> MQ
    EDIT --> MQ
    SHARE --> MQ
    COMMENT --> MQ

    MQ --> PROCESSOR
    PROCESSOR --> ROUTER

    ROUTER --> PUSH
    ROUTER --> EMAIL
    ROUTER --> WS
    ROUTER --> INAPP

Notification Preferences

5. Scalability

“Let me discuss how this system scales to handle 500M users.”

Scaling Strategy

flowchart TB
    subgraph Global["Global Architecture"]
        DNS[DNS] --> GLB[Global Load Balancer]
        GLB --> R1[Region: US]
        GLB --> R2[Region: EU]
        GLB --> R3[Region: Asia]
    end

    subgraph Region["Per Region"]
        LB[Load Balancer]
        subgraph Services["Stateless Services"]
            API1[API 1]
            API2[API 2]
            APIn[API N]
        end
        subgraph Data["Data Layer"]
            SHARD1[(Shard 1)]
            SHARD2[(Shard 2)]
            SHARDN[(Shard N)]
        end
    end

    R1 --> LB
    LB --> API1
    LB --> API2
    LB --> APIn
    API1 --> SHARD1
    API2 --> SHARD2
    APIn --> SHARDN

Scaling by Component

Database Sharding

flowchart TB
    subgraph Sharding["Shard by User ID"]
        ROUTER[Shard Router]
        ROUTER --> S1[Shard 1: Users A-D]
        ROUTER --> S2[Shard 2: Users E-H]
        ROUTER --> S3[Shard 3: Users I-L]
        ROUTER --> SN[Shard N: Users ...]
    end

    subgraph Benefits["Benefits"]
        B1[User's files co-located]
        B2[No cross-shard queries]
        B3[Easy to add shards]
    end

Shard key: user_id

• All files for a user on same shard
• Sharing creates cross-shard references (handled by sharing service)

CDN Strategy

flowchart TB
    subgraph CDN["CDN Distribution"]
        ORIGIN[Origin: Block Storage]
        ORIGIN --> POP1[PoP: Americas]
        ORIGIN --> POP2[PoP: Europe]
        ORIGIN --> POP3[PoP: Asia]
        ORIGIN --> POP4[PoP: Africa]
    end

    subgraph Caching["Cache Strategy"]
        POP1 --> HOT1[Hot files cached]
        HOT1 --> USERS1[Local users]
    end

CDN policies:

• Cache popular public files
• Cache user’s recently accessed files at nearest PoP
• Signed URLs with short TTL for private files

6. Reliability

“For a file storage system, data durability is non-negotiable.”

Data Durability

flowchart TB
    subgraph Write["Write Path"]
        BLOCK[New Block] --> W1[Write to Primary]
        W1 --> W2[Sync to Replica 1]
        W1 --> W3[Sync to Replica 2]
        W2 --> ACK{All replicas ACK?}
        W3 --> ACK
        ACK -->|Yes| SUCCESS[Return success]
        ACK -->|No| RETRY[Retry/Fail]
    end

    subgraph Distribution["Geographic Distribution"]
        PRIMARY[Primary: US-West]
        REP1[Replica 1: US-East]
        REP2[Replica 2: EU-West]
    end

Durability Guarantees

Consistency Model

Failure Handling

stateDiagram-v2
    [*] --> Normal: System healthy

    Normal --> Degraded: Replica failure
    Degraded --> Normal: Replica recovered
    Degraded --> Critical: Multiple failures

    Normal --> Failover: Primary failure
    Failover --> Normal: Failover complete

    Critical --> Recovery: Manual intervention
    Recovery --> Degraded: Partial recovery

Upload Failure Recovery

sequenceDiagram
    participant C as Client
    participant US as Upload Service
    participant BS as Block Storage

    C->>US: Upload chunk 5 (fails)
    US-->>C: Error: timeout

    Note over C: Client retries
    C->>US: Resume upload (upload_id)
    US->>BS: Check existing chunks
    BS-->>US: Chunks 1-4 complete
    US-->>C: Resume from chunk 5
    C->>BS: Upload chunk 5
    C->>BS: Upload chunk 6
    C->>US: Complete upload

7. Additional Considerations

Security

Encryption

Access Control

flowchart TB
    REQ[Request] --> AUTH[Authentication]
    AUTH --> AUTHZ[Authorization]
    AUTHZ --> OWNER{Is owner?}
    OWNER -->|Yes| ALLOW[Allow]
    OWNER -->|No| SHARE{Has share?}
    SHARE -->|Yes| PERM{Check permission}
    SHARE -->|No| DENY[Deny]
    PERM -->|Sufficient| ALLOW
    PERM -->|Insufficient| DENY

Monitoring

Cost Optimization

8. Interview Tips

Key Points to Emphasize

1. Block-level deduplication: Dramatically reduces storage costs
2. Chunked uploads: Enables resume and parallelism
3. Sync complexity: The hardest part - cursor-based, conflict resolution
4. Durability vs. availability: 11 nines durability is non-negotiable

Common Follow-up Questions

Trade-off Discussions

Red Flags to Avoid

• Don’t skip durability discussion - this is critical for file storage
• Don’t ignore conflict resolution - sync is the hardest part
• Don’t propose single-region design - multi-region is expected
• Don’t forget about large files - need chunked uploads

Phrases to Use

9. Summary

Architecture Overview

flowchart TB
    subgraph Client["Client Layer"]
        WEB[Web]
        DESKTOP[Desktop]
        MOBILE[Mobile]
    end

    subgraph Edge["Edge"]
        CDN[CDN]
        LB[Load Balancer]
    end

    subgraph API["API Layer"]
        GW[API Gateway]
        AUTH[Auth]
    end

    subgraph Core["Core Services"]
        META[Metadata]
        UPLOAD[Upload]
        DOWNLOAD[Download]
        SYNC[Sync]
        SHARE[Share]
        NOTIFY[Notify]
    end

    subgraph Data["Data Layer"]
        METADB[(Metadata DB)]
        BLOCKS[(Block Storage)]
        CACHE[(Cache)]
        MQ[Queue]
    end

    Client --> Edge
    Edge --> API
    API --> Core
    Core --> Data

Key Design Decisions

Scale Numbers