Design DropBox

Reference Answer

For a full example answer with detailed architecture diagrams and deep dives, see our Design File System guide.

Problem Statement

Design a file storage and synchronization system like Dropbox that allows users to upload, download, and sync files across multiple devices with real-time updates. Users drop a file in one place and it appears everywhere, even after going offline and reconnecting. The system must handle large files with resumable uploads, multi-device conflict resolution, and cost-efficient distribution through a CDN.

Interviewers ask this because it forces you to separate a control plane (metadata, authentication, sync) from a data plane (large file transfers), handle multi-device real-time updates, and design for large blobs, resumable transfers, conflict resolution, and efficient distribution. Strong answers demonstrate clear requirements, a scalable architecture, and practical trade-offs for reliability, consistency, and user experience.

Key Requirements

Functional

• File upload with resumability -- users can upload files of any size with progress indication, pause/resume support, and automatic recovery from network interruptions
• Browse, search, and download -- users can browse their file tree, search by name or metadata, and download files quickly across devices with accurate listings
• Multi-device synchronization -- files automatically sync across all connected devices, reflecting creates, updates, renames, and deletes, even after being offline
• Sharing and access control -- users can share files or folders with others, controlling view or edit access for collaborators and public links

Non-Functional

• Scalability -- support hundreds of millions of files across millions of users, with efficient handling of files ranging from kilobytes to multiple gigabytes
• Reliability -- zero data loss during uploads, crashes, or network failures, with 99.9% uptime for file access
• Latency -- file metadata operations under 200ms, sync propagation within seconds, and upload/download throughput limited only by network bandwidth
• Consistency -- strong consistency for metadata operations (rename, move, delete) and eventual consistency for file content propagation across devices

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Chunked Uploads and Resumability

Large files over unreliable networks need multipart uploads with checksums and the ability to resume from the last successful chunk. Interviewers want to see that you avoid routing file bytes through application servers.

Hints to consider:

• Split files into fixed-size chunks (e.g., 4-8 MB) and upload each independently with a content hash for deduplication and integrity verification
• Use pre-signed URLs to upload chunks directly to object storage like Amazon S3, keeping application servers out of the data path
• Track upload sessions in a metadata store so clients can resume by querying which chunks are already uploaded
• Only mark a file as complete after all chunks are verified and the manifest is committed atomically

2. Sync Protocol and Conflict Resolution

Multi-device sync requires a reliable mechanism for detecting changes, propagating them, and handling conflicts when the same file is edited on two devices while offline.

Hints to consider:

• Maintain a per-device cursor backed by a server-side change log so each device can request only the changes it missed since its last sync
• Use file content hashes (not timestamps) to detect actual changes and avoid unnecessary transfers
• For conflicts, keep both versions and surface the conflict to the user, or use last-writer-wins for simple cases with automatic renaming for divergent edits
• A push channel (WebSocket or long-poll) notifies online devices of new changes immediately, while offline devices catch up on reconnection

3. Control Plane vs. Data Plane Separation

A key architectural decision is separating the metadata path from the file transfer path. Interviewers look for understanding of why this matters and how to implement it.

Hints to consider:

• The control plane handles authentication, file tree operations, sharing, and sync coordination through your API servers backed by a relational database like PostgreSQL
• The data plane handles actual file bytes through direct client-to-object-storage transfers using pre-signed URLs, with a CDN for downloads
• This separation means a spike in large uploads does not affect metadata responsiveness and allows independent scaling of each plane
• Rate limiting and quota enforcement happen at the control plane before issuing upload tokens

4. Efficient Delta Sync and Deduplication

Transferring entire files on every edit wastes bandwidth. Interviewers appreciate designs that minimize data transfer through content-aware techniques.

Hints to consider:

• Content-defined chunking (like rsync or Rabin fingerprinting) produces stable chunk boundaries so editing the middle of a file only changes affected chunks
• A global chunk deduplication table keyed by content hash means identical chunks across users are stored once
• Delta sync sends only changed chunks, dramatically reducing bandwidth for small edits to large files
• Compression before upload further reduces transfer size, especially for text-heavy content

Suggested Approach

Step 1: Clarify Requirements

Confirm the scope with your interviewer. Key questions include: What is the maximum file size? Is real-time collaboration (like Google Docs) in scope, or just sync? How many devices per user? Is version history required, and for how long? What are the expected read-to-write ratios? Establish whether offline editing and conflict resolution are priorities.

Step 2: High-Level Architecture

Sketch the major components: a client application that monitors the local file system and maintains a sync database; an API gateway for authentication, metadata operations, and sync coordination; a metadata service backed by PostgreSQL for file trees, sharing, and version history; an object storage layer (Amazon S3) for file chunks; a CDN (CloudFront) for fast downloads; a notification service using WebSockets for push-based sync triggers; and a message queue (Kafka) for propagating change events to indexing, thumbnail generation, and antivirus scanning.

Step 3: Deep Dive on Upload and Sync Flow

Walk through the upload flow end to end. The client detects a new or modified file, splits it into chunks using content-defined chunking, computes content hashes, and queries the server for which chunks already exist. For missing chunks, the client requests pre-signed S3 URLs from the API, uploads chunks directly, and notifies the server on completion. The server atomically updates the file metadata and appends an entry to the change log. Connected devices receive a push notification, query the change log for new entries, download only the chunks they lack, and reassemble the file locally. Discuss how offline devices replay the change log on reconnection and how conflicts are detected using content hashes compared against the last-known server state.

Step 4: Address Secondary Concerns

Cover sharing by storing ACLs in PostgreSQL with permission inheritance from folders to files, enforced at every API call. Discuss search using a full-text index over file names and metadata, updated asynchronously via Kafka. Address versioning by retaining previous chunk manifests for a configurable retention period, enabling point-in-time restore. Mention security: encryption at rest in S3, encryption in transit with TLS, and scoped pre-signed URLs with short TTLs.

Real Interview Quotes

"OneDrive Application where we can upload, download and sync when online and how it behaves when offline. There was a lot of focus on designing the client side."

"The focus was on the synchronization across multiple devices. The interviewer pushed hard for versioning solution."

"Dropbox-like SAS service, without sync, with subscription and remove user files who haven't paid, despite multiple notifications."