This document outlines the system design for a cloud-based file storage service like Dropbox, focusing on functional and non-functional requirements, core entities, API, and deep dives.

Made with Rinto — analyse your own content free

Problem Understanding

Dropbox is a cloud-based file storage service for storing and sharing files securely and reliably across devices.

Functional Requirements

Core functional requirements for the Dropbox system are defined, alongside out-of-scope items.

Non-Functional Requirements

Key non-functional requirements for the system, including availability, latency, security, and reliability, are outlined.

System Set Up

The initial setup involves planning the design approach and defining core entities for the system.

Planning Approach

The design strategy involves building sequentially through functional requirements, then using non-functional requirements for deep dives.

Core Entities Definition

Defining primary entities early provides a foundation for the system's API and high-level design.

API or System Interface

Defining the API early guides the high-level design, with endpoints for each functional requirement.

High-Level Design

The high-level design aims to satisfy all functional requirements first, then layer in non-functional requirements.

File Upload Design

Designing how users upload files from any device involves storing file contents and metadata.

Metadata Storage

File metadata can be stored in a NoSQL database like DynamoDB, which supports loosely structured data.

FileMetadata Schema Example

A basic schema includes id, name, size, mimeType, and uploadedBy fields.

Approach 1: Direct to Backend

The simplest approach is uploading files directly to a File Service backend server and storing them on its local file system.

Approach 2: Store in Blob Storage

A better approach is storing files in a Blob Storage service (e.g., Amazon S3, Google Cloud Storage) while metadata goes to the database.

Approach 3: Direct Upload to Blob Storage

The best approach allows users to upload files directly to Blob Storage from the client using presigned URLs.

File Download Design

Designing how users download files from any device involves several approaches.

Approach 1: Via Backend

The most common solution involves downloading the file first from Blob Storage to the backend, then to the client.

Approach 2: Direct from Blob Storage

A better approach is allowing users to download files directly from Blob Storage using presigned URLs.

Approach 3: Via Content Delivery Network (CDN)

The best approach uses a CDN to cache files closer to users, reducing latency and speeding up downloads.

File Sharing Design

To support file sharing, the system needs an efficient mechanism to manage access for other users.

Approach 1: Sharelist in Metadata

A simple approach is adding a list of users with access (sharelist) directly to the file metadata.

Approach 2: Cached Inverse Mapping

A better approach caches an inverse mapping from a user to the files shared with them, in addition to the sharelist.

Approach 3: Normalized Data Table

Another approach fully normalizes data by creating a new SharedFiles table mapping userId to fileId.

File Sync Design

Automatic file synchronization across devices requires handling changes from local to remote and remote to local.

Local to Remote Sync

When a user updates a file locally, changes must sync to the remote server, considered the source of truth.

Remote to Local Sync

Clients need to detect and pull changes from the remote server to their local devices.

Tying It All Together: Final System

A holistic view of the system components satisfying all functional requirements.

Potential Deep Dives

This section explores specific challenges and advanced solutions for the Dropbox system design.

Support for Large Files

Designing for large files requires addressing user experience and technical limitations of single requests.

User Experience Insights

Key user experience insights for large files include progress indicators and resumable uploads.

Limitations of Single POST Request

Uploading large files via a single POST request faces several limitations.

Chunking for Large Files

Chunking breaks files into smaller pieces (e.g., 5-10 MB) for individual or parallel uploads.

Resumable Uploads with Chunking

Resumable uploads require tracking uploaded and remaining chunks, saving state in FileMetadata.

Unique File and Chunk Identification

Resuming uploads requires uniquely identifying files and individual chunks.

Detailed Large File Upload Process

The comprehensive process for uploading a large file with chunking and fingerprinting involves multiple steps.

S3 Multipart Upload Feature

Cloud storage providers like Amazon S3 offer a Multipart Upload feature that handles large objects in parts.

Chunked Downloads Not Needed

Chunked downloads are generally not needed as S3 assembles parts into a single object after multipart upload completion.

Speed Optimization

Optimizing uploads, downloads, and syncing involves several techniques beyond basic approaches.

Download Speed: CDN

CDNs cache files closer to the user, reducing latency and speeding up download times.

Upload Speed: Chunking

Chunking maximizes bandwidth utilization by sending multiple chunks in parallel and adjusting sizes.

Sync Speed: Chunking

For syncing, chunking allows only changed chunks to be transferred, significantly speeding up the process.

Content-Defined Chunking (CDC)

CDC uses rolling hashes to determine chunk boundaries based on content, making delta sync efficient for small edits.

Compression for Speed

Compression reduces file size, meaning fewer bytes need to be transferred, speeding up uploads and downloads.

File Security

Ensuring file security involves encryption in transit, encryption at rest, and robust access control.

Interview Expectations by Level

Expectations for system design interviews vary significantly based on candidate experience level (Mid-level, Senior, Staff+).

Candidate Expectations: Dropbox Problem

This comparison outlines the expected scope and depth of knowledge for Mid-level, Senior, and Staff+ candidates tackling the Dropbox system design problem.

Level	Breadth vs Depth	Driving/Proactivity	Dropbox Problem Bar
Mid-level (E4)	80% Breadth / 20% Depth	Drives early, interviewer probes basics and drives later stages	Defines API, data model, functional high-level design; reasons through probing questions.
Senior (E5)	60% Breadth / 40% Depth	Proactive; anticipates challenges and suggests improvements	Quickly through high-level design; deep discussion on large files, multipart upload, trade-offs.
Staff+ (E6+)	40% Breadth / 60% Depth	Exceptional proactivity; identifies and solves issues independently, interviewer only focuses	Deep dive into nuances, practical application of technologies, confident solutions from experience, treats interviewer as peer.

▸ 8 Expand

APEX

Dropbox System Design

This document outlines the system design for a cloud-based file storage service like Dropbox, focusing on functional and non-functional requirements, core entities, API, and deep dives.

Made with Rinto — analyse your own content free

CONC

Problem Understanding

Dropbox is a cloud-based file storage service for storing and sharing files securely and reliably across devices.

▸ 7 Expand

CONC

Functional Requirements

Core functional requirements for the Dropbox system are defined, alongside out-of-scope items.

DETL

Core: Upload Files

Users should be able to upload a file from any device.

DETL

Core: Download Files

Users should be able to download a file from any device.

DETL

Core: Share Files

Users should be able to share files with others and view shared files.

DETL

Core: Sync Files

Users can automatically sync files across devices.

DETL

Out of Scope: Edit Files

Users should not be able to edit files directly within the system.

DETL

Out of Scope: View Without Download

Users should not be able to view files without downloading them first.

INSG

Blob Storage Design Out of Scope

Designing Blob Storage itself is outside the scope of this problem, but researching it is suggested.

▸ 8 Expand

CONC

Non-Functional Requirements

Key non-functional requirements for the system, including availability, latency, security, and reliability, are outlined.

DETL

Core: High Availability

The system should prioritize availability over consistency.

DETL

Core: Large File Support

The system should support files as large as 50GB.

DETL

Core: Security and Reliability

The system should be secure, reliable, and able to recover lost or corrupted files.

DETL

Core: Low Latency

Upload, download, and sync times should be as fast as possible.

DETL

Out of Scope: Storage Limit

The system should not have a storage limit per user.

DETL

Out of Scope: File Versioning

The system should not support file versioning.

DETL

Out of Scope: Virus Scanning

The system should not scan files for viruses and malware.

▸ 2 Expand

INSG

CAP Theorem Trade-off

For file storage, prioritizing availability over consistency is acceptable, unlike applications requiring immediate consistency.

EXMP

Stock Trading App Consistency

A stock trading app requires consistency, meaning a buy transaction must be replicated globally before subsequent buys.

EXMP

Dropbox Eventual Consistency

For Dropbox, it is acceptable if an uploaded file is not immediately visible globally for a few seconds.

▸ 3 Expand

CONC

System Set Up

The initial setup involves planning the design approach and defining core entities for the system.

DCSN

Planning Approach

The design strategy involves building sequentially through functional requirements, then using non-functional requirements for deep dives.

▸ 3 Expand

CONC

Core Entities Definition

Defining primary entities early provides a foundation for the system's API and high-level design.

DETL

File Entity

The File entity represents the raw data that users upload, download, and share.

DETL

FileMetadata Entity

FileMetadata includes information like file name, size, mime type, and uploader.

DETL

User Entity

The User entity represents the system's users.

▸ 8 Expand

CONC

API or System Interface

Defining the API early guides the high-level design, with endpoints for each functional requirement.

DETL

Upload API Endpoint

An initial endpoint for uploading a file might be POST /files with File and FileMetadata in the request.

DETL

Download API Endpoint

An initial endpoint for downloading a file can be GET /files/{fileId} returning File & FileMetadata.

DETL

Share API Endpoint

An initial endpoint for sharing a file might be POST /files/{fileId}/share with an array of User IDs.

DETL

Sync API Endpoint

An endpoint to query changes for syncing can be GET /files/changes?since={timestamp} returning ChangeEvent[].

DETL

ChangeEvent Details

Each ChangeEvent includes fileId, change type (created, updated, deleted), and updated metadata.

INSG

API Evolution Expectation

APIs may change or evolve during the design process, which should be communicated to the interviewer.

DETL

User Info in Headers

User authentication information (session token or JWT) should be passed in request headers for security.

JUST

Avoid User Info in Body

Passing user information in the request body should be avoided as it can be manipulated by the client.

▸ 4 Expand

CONC

High-Level Design

The high-level design aims to satisfy all functional requirements first, then layer in non-functional requirements.

▸ 5 Expand

CONC

File Upload Design

Designing how users upload files from any device involves storing file contents and metadata.

DETL

Metadata Storage

File metadata can be stored in a NoSQL database like DynamoDB, which supports loosely structured data.

DETL

FileMetadata Schema Example

A basic schema includes id, name, size, mimeType, and uploadedBy fields.

▸ 1 Expand

CONC

Approach 1: Direct to Backend

The simplest approach is uploading files directly to a File Service backend server and storing them on its local file system.

CONC

Challenges: Direct to Backend

This approach has scalability and reliability issues as file numbers grow and server failures occur.

▸ 3 Expand

CONC

Approach 2: Store in Blob Storage

A better approach is storing files in a Blob Storage service (e.g., Amazon S3, Google Cloud Storage) while metadata goes to the database.

JUST

Blob Storage Benefits

Blob Storage handles scaling, offers high reliability, and provides features like lifecycle policies and versioning.

CONC

Challenges: Store in Blob Storage

This approach is more complex, requiring integration with Blob Storage and handling transactional consistency between file and metadata uploads.

DETL

Double Upload Redundancy

This approach redundantly uploads files twice: once to the backend and once to Blob Storage.

▸ 7 Expand

CONC

Approach 3: Direct Upload to Blob Storage

The best approach allows users to upload files directly to Blob Storage from the client using presigned URLs.

JUST

Direct Upload Benefits

Direct upload is faster and cheaper, bypassing the backend server for file transfer.

DETL

Presigned URL Purpose

Presigned URLs grant temporary permission to upload a file to a specific Blob Storage location.

DETL

Three-Step Upload Process

The upload process becomes a three-step sequence involving requesting a URL, uploading, and notification.

DETL

Step 1: Request Presigned URL

Client requests a presigned URL from the backend, which saves file metadata with 'uploading' status.

DETL

Step 2: Upload to Blob Storage

Client uses the presigned URL for a PUT request to upload the file directly to Blob Storage.

DETL

Step 3: Update Metadata

Blob Storage sends a notification to the backend, which updates file metadata status to 'uploaded'.

INSG

Pattern: Handling Large Blobs

Direct upload with presigned URLs is a classic pattern for efficient large file transfers, bypassing application servers for data transfer.

▸ 3 Expand

CONC

File Download Design

Designing how users download files from any device involves several approaches.

▸ 1 Expand

CONC

Approach 1: Via Backend

The most common solution involves downloading the file first from Blob Storage to the backend, then to the client.

CONC

Challenges: Via Backend

This approach is suboptimal, leading to slower speeds and increased costs due to double downloads.

▸ 2 Expand

CONC

Approach 2: Direct from Blob Storage

A better approach is allowing users to download files directly from Blob Storage using presigned URLs.

DETL

Presigned URL Download Process

Client requests a presigned download URL from the backend, then uses it to download the file directly.

CONC

Challenges: Direct from Blob Storage

While nearly optimal, this approach can be slow for geographically distributed users due to single-region Blob Storage.

▸ 5 Expand

CONC

Approach 3: Via Content Delivery Network (CDN)

The best approach uses a CDN to cache files closer to users, reducing latency and speeding up downloads.

JUST

CDN Benefits

CDNs serve files from the closest server, significantly faster than direct backend or Blob Storage access.

DETL

CDN Signed URLs

For security, CDN signed URLs provide temporary, permission-based access for file downloads.

CONC

Challenges: CDN Cost Management

CDNs are expensive, requiring strategic caching policies for file caching duration and invalidation.

DETL

Cache Control Headers

Cache control headers specify how long files should be cached, optimizing cost and performance.

DETL

Cache Invalidation

Cache invalidation removes updated or deleted files from the CDN to ensure fresh content.

▸ 3 Expand

CONC

File Sharing Design

To support file sharing, the system needs an efficient mechanism to manage access for other users.

▸ 2 Expand

CONC

Approach 1: Sharelist in Metadata

A simple approach is adding a list of users with access (sharelist) directly to the file metadata.

DETL

Metadata Sharelist Example

The file metadata schema would include a 'sharelist' field, e.g., 'sharelist': ['user2', 'user3'].

CONC

Challenges: Sharelist Query Performance

Retrieving files shared *with* a user is slow, requiring scanning every file's sharelist.

▸ 3 Expand

CONC

Approach 2: Cached Inverse Mapping

A better approach caches an inverse mapping from a user to the files shared with them, in addition to the sharelist.

DETL

Cache Entry Example

A cache entry would look like 'user1': ['fileId1', 'fileId2'] for quick lookup.

CONC

Challenges: Cache Sync

The main challenge is keeping the cached sharedFiles list in sync with the sharelist in the file metadata.

DCSN

Sync Solution: Transactional Update

The best way to overcome sync issues is updating both sharelist and sharedFiles list within a transaction.

▸ 4 Expand

CONC

Approach 3: Normalized Data Table

Another approach fully normalizes data by creating a new SharedFiles table mapping userId to fileId.

DETL

SharedFiles Table Schema

The SharedFiles table has 'userId' (Partition Key) and 'fileId' (Sort Key) forming a composite primary key.

JUST

Eliminate Sharelist Sync

This design removes the need for a 'sharelist' in file metadata and eliminates sync issues.

CONC

Challenges: Query Efficiency

This query is slightly less efficient due to index-based querying instead of a simple key-value lookup.

JUST

Tradeoff: Sync vs Query

The trade-off of slightly less efficient queries is often worth eliminating the need to sync sharelists.

▸ 2 Expand

CONC

File Sync Design

Automatic file synchronization across devices requires handling changes from local to remote and remote to local.

▸ 5 Expand

CONC

Local to Remote Sync

When a user updates a file locally, changes must sync to the remote server, considered the source of truth.

DETL

Client-Side Sync Agent

A client-side sync agent monitors local folder changes using OS-specific file system events.

DETL

Upload Queue

Upon detecting a change, the agent queues the modified file for local upload.

DETL

Upload API Usage

The agent uses the upload API to send changes and updated metadata to the server.

DETL

Conflict Resolution Strategy

Conflicts are resolved using a 'last write wins' strategy, saving the most recent edit.

INSG

Versioning for Overwriting

Versioning, though out of scope, would typically add new chunks/files rather than overwriting the only file.

▸ 3 Expand

CONC

Remote to Local Sync

Clients need to detect and pull changes from the remote server to their local devices.

▸ 1 Expand

CONC

Approach 1: Polling

The client periodically queries the server for changes since its last sync, using `updatedAt` timestamps.

CONC

Polling Challenges

Polling is simple but can be slow to detect changes and wastes bandwidth if nothing has changed.

▸ 1 Expand

CONC

Approach 2: WebSocket or SSE

The server maintains an open connection (WebSocket or SSE) with each client to push real-time change notifications.

CONC

WebSocket/SSE Challenges

This approach is more complex but provides real-time updates.

▸ 3 Expand

CONC

Hybrid Sync Approach

A hybrid approach combines WebSocket/SSE for real-time updates with periodic polling as a safety net.

DETL

Active Notification via WebSocket

The server pushes change events in real-time through a single WebSocket connection per device/session.

DETL

Periodic Polling Safety Net

Clients periodically poll (e.g., every few minutes) using GET /files/changes?since={timestamp} to catch missed changes.

JUST

Hybrid Approach Benefits

This approach provides real-time updates and guarantees eventual consistency even with connection interruptions.

▸ 8 Expand

CONC

Tying It All Together: Final System

A holistic view of the system components satisfying all functional requirements.

DETL

Uploader Component

The client (web, mobile, or desktop app) uploads files and proactively identifies and pushes local changes.

DETL

Downloader Component

The client (potentially same as uploader) downloads files and determines when local files need remote updates.

DETL

LB & API Gateway

Handles routing requests, SSL termination, rate limiting, and request validation for application servers.

DETL

File Service

Manages file metadata in the database and generates presigned URLs using the S3 SDK without direct file handling.

DETL

File Metadata DB

Stores file metadata (name, size, MIME type, uploader) and a shared files table for permissions enforcement.

DETL

S3 (Blob Storage)

Stores actual file contents, with direct uploads facilitated by presigned URLs from the file service.

DETL

CDN (CloudFront)

Caches files globally to reduce latency; serves files from the nearest edge location using signed URLs.

DETL

CDN Fetch Process

CDN fetches files from S3 on a cache miss and serves from the edge on subsequent requests.

▸ 3 Expand

CONC

Potential Deep Dives

This section explores specific challenges and advanced solutions for the Dropbox system design.

▸ 8 Expand

CONC

Support for Large Files

Designing for large files requires addressing user experience and technical limitations of single requests.

INSG

User Experience Insights

Key user experience insights for large files include progress indicators and resumable uploads.

▸ 4 Expand

CONC

Limitations of Single POST Request

Uploading large files via a single POST request faces several limitations.

▸ 1 Expand

DETL

Timeout Issues

Web servers and clients have timeout settings, which a 50GB file upload can easily exceed.

STAT

50GB Upload Time Calculation

A 50GB file at 100Mbps takes approximately 1.11 hours to upload.

▸ 1 Expand

DETL

Browser and Server Limitations

Browsers and web servers, like Amazon API Gateway, often impose strict limits on request payload sizes.

STAT

API Gateway Size Limit

Amazon API Gateway has a hard limit of 10MB for request payloads.

DETL

Network Interruptions

Large files are more susceptible to network interruptions, forcing uploads to restart from scratch.

DETL

Poor User Experience

Users lack progress visibility, not knowing upload status or estimated completion time.

▸ 2 Expand

CONC

Chunking for Large Files

Chunking breaks files into smaller pieces (e.g., 5-10 MB) for individual or parallel uploads.

JUST

Client-Side Chunking

Chunking must be done on the client side to effectively bypass server payload limitations.

DETL

Progress Indicator with Chunking

Chunking allows tracking and updating a progress bar for each successfully uploaded chunk, improving UX.

▸ 3 Expand

CONC

Resumable Uploads with Chunking

Resumable uploads require tracking uploaded and remaining chunks, saving state in FileMetadata.

DETL

FileMetadata Chunks Field

The FileMetadata schema includes a 'chunks' field, listing each chunk's ID and status (uploaded, uploading, not-uploaded).

▸ 1 Expand

CONC

Chunk Status Sync Approach 1: Client Orchestration

The client uploads chunks to S3, then sends PATCH requests to the backend to update chunk statuses in FileMetadata.

CONC

Challenges: Client Orchestration Security

This approach risks security and inconsistent states as a malicious client could fake chunk upload statuses.

▸ 1 Expand

CONC

Chunk Status Sync Approach 2: Server-Side Verification

A better approach implements server-side verification of chunk uploads using ETags and S3's ListParts API.

JUST

Trust but Verify Principle

This approach balances user experience with data integrity by accepting client updates but periodically verifying server-side.

▸ 2 Expand

CONC

Unique File and Chunk Identification

Resuming uploads requires uniquely identifying files and individual chunks.

DETL

File Fingerprinting

A fingerprint (cryptographic hash like SHA-256) identifies file content for deduplication and resumability.

DETL

Chunk-Level Fingerprinting

Generating fingerprints for each chunk allows precise identification of transmitted parts for resumable uploads.

▸ 6 Expand

CONC

Detailed Large File Upload Process

The comprehensive process for uploading a large file with chunking and fingerprinting involves multiple steps.

DETL

Step 1: Client Chunking & Fingerprinting

The client chunks the file into 5-10MB pieces, calculating fingerprints for each chunk and the entire file.

DETL

Step 2: Check for Existing File

Client checks if a file with the same fingerprint exists and is 'uploading' to resume the upload.

DETL

Step 3: Initiate Multipart Upload

If new, client POSTs to initiate a multipart upload; backend gets an S3 uploadId, generates chunk presigned URLs, and saves metadata.

DETL

Step 4: Upload Chunks & Update Status

Client uploads each chunk to S3, then PATCHes backend with chunk status and ETag; backend verifies and updates metadata.

DETL

Step 5: Complete Multipart Upload

Once all chunks are uploaded, backend calls S3's CompleteMultipartUpload API, then updates file metadata to 'uploaded'.

DETL

Client UI Responsibility

Throughout the process, the client is responsible for tracking upload progress and updating the user interface.

▸ 3 Expand

CONC

S3 Multipart Upload Feature

Cloud storage providers like Amazon S3 offer a Multipart Upload feature that handles large objects in parts.

INSG

Multipart Upload Interview Expectation

Candidates are expected to explain S3 Multipart Upload mechanics, not just state its use, to show understanding.

DETL

Multipart Upload Notifications

S3 event notifications only trigger when the entire multipart upload is completed, not for individual part uploads.

DETL

Tracking Individual Part Progress

To track individual part progress, S3's ListParts API can be used, which returns uploaded parts and their ETags.

▸ 2 Expand

CONC

Chunked Downloads Not Needed

Chunked downloads are generally not needed as S3 assembles parts into a single object after multipart upload completion.

DETL

Normal File Downloads

After assembly, downloads work like any normal file, using a single presigned or CDN signed URL.

DETL

HTTP Range Requests for Large Files

For very large files, S3 and HTTP support Range requests, enabling parallel or resumable byte range downloads.

▸ 5 Expand

CONC

Speed Optimization

Optimizing uploads, downloads, and syncing involves several techniques beyond basic approaches.

DETL

Download Speed: CDN

CDNs cache files closer to the user, reducing latency and speeding up download times.

DETL

Upload Speed: Chunking

Chunking maximizes bandwidth utilization by sending multiple chunks in parallel and adjusting sizes.

DETL

Sync Speed: Chunking

For syncing, chunking allows only changed chunks to be transferred, significantly speeding up the process.

▸ 2 Expand

CONC

Content-Defined Chunking (CDC)

CDC uses rolling hashes to determine chunk boundaries based on content, making delta sync efficient for small edits.

JUST

Fixed-Size Chunking Issue

Fixed-size chunking makes delta sync useless because a small edit shifts all subsequent chunk boundaries.

EXMP

Rabin Fingerprinting for CDC

Systems like Dropbox use Rabin fingerprinting for CDC to achieve efficient delta sync.

▸ 6 Expand

CONC

Compression for Speed

Compression reduces file size, meaning fewer bytes need to be transferred, speeding up uploads and downloads.

JUST

Client-Side Compression

Compression happens on the client before uploading to S3, and decompression happens on the client after downloading.

DETL

Smart Compression Logic

Client-side logic should decide whether to compress based on file type, size, and network conditions.

EXMP

Media Files Compression

Media files like images and videos have low compression ratios, making compression often not worthwhile.

EXMP

Text Files Compression

Text files can achieve high compression ratios, potentially reducing a 5GB file to 1GB or less.

▸ 4 Expand

CONC

Compression Algorithms

Common compression algorithms include Gzip, Brotli, and Zstandard, each with tradeoffs in ratio and speed.

DETL

Gzip Algorithm

Gzip is widely used and broadly supported.

DETL

Brotli Algorithm

Brotli generally offers better compression ratios than Gzip, especially for text, and is supported by modern browsers.

DETL

Zstandard (zstd) Algorithm

Zstandard provides an excellent balance of speed and compression ratio, compressing and decompressing faster than Gzip.

DCSN

Zstandard for Client-Side Compression

Zstandard is a strong choice for client-side compression due to its fast compression speed.

INSG

Compress Before Encrypting

Always compress files before encrypting them, as encryption introduces randomness that hinders compression.

▸ 3 Expand

CONC

File Security

Ensuring file security involves encryption in transit, encryption at rest, and robust access control.

DETL

Encryption in Transit (HTTPS)

Using HTTPS encrypts data transfer between client and server, a standard practice supported by modern browsers.

DETL

Encryption at Rest (S3)

Encrypting files stored in S3 is a native feature; S3 encrypts files with unique keys stored separately.

▸ 6 Expand

CONC

Access Control (ACL)

The shareList or separate share table/cache serves as the basic Access Control List (ACL).

DETL

Signed URLs for Secure Downloads

Download links are generated as signed URLs, valid only for a short period (e.g., 5 minutes).

INSG

Signed URLs as Bearer Tokens

Signed URLs are bearer tokens, meaning anyone with a valid, unexpired URL can download the file.

JUST

Short Expiration for Security

A short expiration window limits exposure but does not fully prevent unauthorized sharing.

DETL

CDN Signed URL Generation

Signed URLs are generated on the server, incorporating a signature, expiration timestamp, and optional restrictions.

DETL

CDN Signed URL Distribution

The signed URL is distributed to an authorized user to access the resource directly from the CDN.

DETL

CDN Signed URL Validation

CDN verifies the signature, expiration, and restrictions; serves content if valid, denies access otherwise.

▸ 1 Expand

CONC

Interview Expectations by Level

Expectations for system design interviews vary significantly based on candidate experience level (Mid-level, Senior, Staff+).

CMPR

Candidate Expectations: Dropbox Problem

This comparison outlines the expected scope and depth of knowledge for Mid-level, Senior, and Staff+ candidates tackling the Dropbox system design problem.

Level	Breadth vs Depth	Driving/Proactivity	Dropbox Problem Bar
Mid-level (E4)	80% Breadth / 20% Depth	Drives early, interviewer probes basics and drives later stages	Defines API, data model, functional high-level design; reasons through probing questions.
Senior (E5)	60% Breadth / 40% Depth	Proactive; anticipates challenges and suggests improvements	Quickly through high-level design; deep discussion on large files, multipart upload, trade-offs.
Staff+ (E6+)	40% Breadth / 60% Depth	Exceptional proactivity; identifies and solves issues independently, interviewer only focuses	Deep dive into nuances, practical application of technologies, confident solutions from experience, treats interviewer as peer.