Design Dropbox / Google Drive

By /

Design a file storage and sync service like Dropbox or Google Drive. This problem tests your ability to handle large binary data, eventual consistency across devices, conflict resolution, and the subtle difference between metadata and content storage.

Requirements Clarification

Start by defining scope:

  • Users: 500M registered, 50M daily active
  • Storage per user: 15GB free tier, average user stores 5GB
  • File types: All types — documents, photos, videos, code
  • Features: Upload, download, sync across devices, share with others, version history (30 days)
  • Consistency model: Strong consistency for metadata (you must always see the current folder structure). Eventual for content is acceptable — if your laptop and phone both edit the same file offline, we handle conflicts explicitly.

Back-of-Envelope

  • 500M users × 5GB avg = 2.5 petabytes of stored data
  • 50M DAU, avg 1 upload/day, avg file size 500KB → 25TB uploaded per day → ~300MB/sec sustained
  • Downloads: typically 3–5× uploads → ~1GB/sec download throughput needed
  • Metadata operations: folder browsing, search → ~10M requests/sec (low data, high QPS)

The key architectural insight: metadata (filenames, folder structure, permissions) and content (actual file bytes) have wildly different requirements. Separate them completely.

High-Level Architecture

Client (Desktop/Mobile)
    ↕  Metadata API (HTTPS/REST)       ↕  Block Upload API (HTTPS)
Metadata Service ←→ MySQL (sharded)    Block Service ←→ S3/Object Store
         ↓                                      ↓
Notification Service (WebSocket)        CDN (CloudFront/Fastly)

The Key Insight: Block-Level Storage

Don’t store files as atomic units. Split each file into fixed-size blocks (4MB is typical). This unlocks three capabilities:

Deduplication: Hash each block with SHA-256. If two files share a block (e.g., two versions of a document with minor edits), store the block only once. Dropbox reported 70%+ storage savings from block dedup in early public filings.

Delta sync: When a file changes, only re-upload the changed blocks. Edit a 1GB video’s metadata: the thumbnail block changes, the video data blocks don’t. Upload ~4MB instead of 1GB.

Parallel upload: Upload all blocks concurrently across multiple connections, maximizing throughput on high-latency mobile connections.

Upload Flow

  1. Client splits file into 4MB blocks, hashes each block (SHA-256)
  2. Client sends block hashes to Metadata API: “I want to upload file X with these block hashes”
  3. Metadata API checks Block Service: which hashes already exist?
  4. API responds: “upload only blocks [B2, B5] — the rest we already have” (dedup)
  5. Client uploads only the missing blocks directly to Block Service (presigned S3 URL)
  6. Client notifies Metadata API: “upload complete, file X now points to blocks [B1, B2, B3, B4, B5]”
  7. Metadata API updates the file record, notifies all other devices via Notification Service

Metadata Service

Stores the logical structure of the filesystem:

files table:
  file_id   UUID  PK
  owner_id  UUID  FK users
  name      VARCHAR(255)
  parent_id UUID  FK files (NULL for root)
  size      BIGINT
  created_at, updated_at TIMESTAMP
  is_deleted BOOLEAN (soft delete for trash)

file_versions table:
  version_id UUID  PK
  file_id    UUID  FK
  block_ids  JSON  -- ordered list of block hashes
  created_at TIMESTAMP
  created_by UUID

blocks table:
  block_hash CHAR(64)  PK  -- SHA-256 hex
  size       INTEGER
  ref_count  INTEGER   -- for garbage collection

Metadata DB is sharded by owner_id. All files for one user live on the same shard — this keeps folder listing queries local. Cross-user sharing uses a separate permissions table + lookup.

Sync Across Devices

When device A uploads a file, device B needs to find out quickly. Three options:

  • Polling: Device asks “any changes since timestamp T?” every 30s. Simple, but 30s delay and wasteful.
  • Long-polling: Device opens a request; server holds it open until there’s a change. Better latency, but harder to scale.
  • WebSocket / SSE: Persistent connection. Server pushes change events immediately. Dropbox migrated to this.

The Notification Service maintains a WebSocket connection per active device. When Metadata API records a change, it publishes to a message queue (Kafka). Notification workers fan out to all connected devices for that user.

Conflict Resolution

User edits file on laptop (offline) and phone (offline). Both go online. Now what?

Dropbox’s approach: last-writer-wins + conflict copy. When the second upload arrives, if the parent version doesn’t match what the client started from, create a “Conflicted Copy” — a second file named “report (Michael’s conflicted copy 2026-04-15).docx”. The user resolves manually.

Google Docs uses CRDTs (Conflict-free Replicated Data Types) for real-time collaborative editing — much more complex. For a file sync service, conflict copy is the right trade-off.

Download and CDN

For downloads, clients get presigned S3 URLs with short TTLs (15 minutes). Popular files (shared docs with many viewers) are served via CDN — CloudFront or Fastly caches the blocks at edge locations. The CDN key is the block hash, which is immutable by definition (content-addressed storage), so CDN caching is trivially correct.

Version History

Every upload creates a new entry in file_versions. To restore: update the file’s current_version pointer to the old version_id. Old block data is retained for 30 days, then subject to garbage collection (decrement ref_count on blocks; delete blocks with ref_count = 0).

Trade-offs

4MB block size: Too small → too many blocks to track for large files. Too large → small edits require re-uploading large blocks. 4MB is the industry sweet spot. Some systems use variable-size blocks (Rabin fingerprinting) for better delta compression.

Strong vs eventual consistency for metadata: Users would lose trust if a folder appeared empty right after uploading a file. Strong consistency for metadata is worth the performance cost.

Client-side dedup vs server-side: Hashing on the client prevents uploading known blocks. Privacy concern: the server learns “user has a file with this hash” without seeing content. Dropbox’s 2011 dedup implementation was criticized for this — it allowed proving file possession without access. Production systems often make this configurable.

Interview Follow-ups

  • How would you implement real-time collaborative editing (Google Docs-style) on top of this architecture?
  • How does the block GC system work without accidentally deleting live blocks?
  • A user’s laptop is stolen. How do you implement remote wipe?
  • How do you handle extremely large files (10GB+ video)? What changes in the upload flow?
  • Design the search feature: full-text search across all user files.

Related System Design Topics

  • Database Sharding — sharding the metadata service by owner_id for local folder queries
  • Caching Strategies — block content-addressed cache and metadata hot-path cache
  • Message Queues — Kafka change feed to fan out sync notifications to all devices
  • CAP Theorem — strong consistency for metadata, eventual for block storage
  • Consistent Hashing — routing block uploads to the right storage node

Companies That Ask This System Design Question

This problem type commonly appears in interviews at:

See our company interview guides for full interview process, compensation, and preparation tips.

Scroll to Top