Design Google Drive / Dropbox — System Design Walkthrough

"Design Google Drive" — or its near-twin "Design Dropbox" — is a staple file storage system design interview question. It looks like "just store files," but it forces you to confront huge binary objects, multi-device sync, conflicts, sharing, and the question of what stays strongly consistent. Below is a structured cloud storage system design walkthrough you can mirror in a real interview, narrating each stage as you go. Keep the system design interview cheat sheet open alongside for the underlying template.

1. Clarify the requirements

Don't start drawing boxes. Scope the problem first so you optimize the right thing.

Functional requirements

• A user can upload and download files, and organize them into folders.
• Files sync automatically across a user's devices.
• A user can share a file or folder with others, with permissions (view / edit).
• The system keeps version history so changes can be recovered.

Non-functional requirements

• Durability first: never lose a user's file — many 9s of durability.
• Availability: uploads/downloads should keep working through partial failures.
• Efficient bandwidth & storage: avoid re-transferring and re-storing unchanged data.
• Scale: hundreds of millions of users and exabytes of data, with large individual files.

I'll de-scope real-time collaborative editing (Google Docs-style operational transforms) and full-text search for now — calling that out shows judgment without burning time.

2. Scale estimates (back-of-the-envelope)

Rough numbers justify the architecture; precision isn't the point.

The headline takeaways: storage is enormous (so dedup matters a lot), files are big binary objects (so they don't belong in a database), and the metadata is small but accessed constantly. That split drives the whole architecture in sections 4 and 5.

3. API design

A small surface covers it. Uploads are chunked and resumable; the metadata commit is separate from the byte transfer.

POST /v1/files/upload-init   { name, parentFolderId, size, chunkHashes:[...] }
       -> { fileId, missingChunks:[...] }   // server says which chunks it lacks

PUT  /v1/blocks/{chunkHash}   (binary)      // upload only missing chunks
POST /v1/files/commit         { fileId, version, orderedChunkHashes:[...] }

GET  /v1/files/{fileId}                      // metadata + chunk list
GET  /v1/blocks/{chunkHash}                  // download a chunk (via CDN)
POST /v1/files/{fileId}/share { userId, role }
GET  /v1/changes?cursor=...                  // sync: changes since last cursor

Note upload-init returns missingChunks — the client only uploads chunks the system doesn't already have. That single step is what powers both delta sync and deduplication.

4. The core idea: chunking and deduplication

The central decision in file storage system design is to never treat a file as one opaque blob. Instead, split each file into fixed-size chunks (commonly ~4MB) and content-address each chunk by its hash (e.g., SHA-256).

• Resumable, parallel uploads. Chunks transfer independently; a dropped connection resumes from the last completed chunk.
• Delta sync. When a file changes, only the chunks whose content (and therefore hash) changed are re-uploaded. Editing one page of a large document moves a few megabytes, not the whole file.
• Deduplication. Because chunks are stored under their hash, two identical chunks — in the same file, across files, or across users — are stored exactly once. Before storing, check if the hash already exists; if so, just record a reference.

5. Architecture diagram

Clients talk to stateless services behind a gateway; metadata and blob paths diverge.

                    ┌──────────────┐
   ┌────────┐  meta  │  Metadata    │   names, folders, versions,
   │ Client │ ─────► │  service     │── permissions, chunk-hash lists
   │ (sync  │ ◄───── │  (strong DB) │   (sharded by userId)
   │  agent)│  list  └──────┬───────┘
   └───┬────┘               │ change events
       │ chunks             ▼
       │              ┌──────────────┐   pub/sub
       │   missing?   │ Notification │──► other devices pull /changes
       ▼   ──────────►│   service    │
   ┌──────────────┐   └──────────────┘
   │ Block / blob │   content-addressed chunks (hash → bytes)
   │ store + CDN  │   highly durable object storage, dedup'd
   └──────────────┘

6. Sync and conflict handling

Sync is the part interviewers probe hardest. Each device runs a sync agent that watches the local folder and the server:

• Upload path: on a local change, the agent chunks the file, asks the metadata service which chunks are missing, uploads only those, then commits a new version.
• Download path: the agent polls (or holds a long-lived connection to) the notification service for a change cursor; on a change it pulls the new metadata and fetches any missing chunks.

Conflicts. Two devices can edit the same file version offline. Every change is versioned, and the metadata service orders writes; when it sees a commit against a version that has already been superseded, it does not silently overwrite. Instead it preserves both — the standard move is to create a "conflicted copy" (e.g., report (Alex's conflicted copy).docx) so no data is lost, leaving the user to reconcile. Version history makes any prior state recoverable.

7. Sharing, permissions, and consistency

Sharing lives entirely in the metadata service. A file or folder has an access-control list mapping users (or links) to roles (viewer/editor). A request to read or write checks the ACL before serving any chunk.

This is where you make a sharp consistency call:

• Metadata: strongly consistent. Permissions and the file tree must never serve a stale view — if an owner revokes access, the next request should reflect it. Keep metadata in a strongly consistent store, sharded by userId/workspace.
• Blobs: eventually consistent. Chunk bytes are immutable and content-addressed, so they can replicate across regions lazily; a few seconds of propagation delay before another device sees a new file is fine.

Naming this metadata-strong / blob-eventual split is the highest-signal moment of the interview — it shows you know which guarantees actually matter where.

8. Scaling and bottlenecks

• Blob durability. Replicate chunks (or use erasure coding) across machines and regions for many-9s durability; serve hot downloads from a CDN so heavy bytes never hit your app servers.
• Metadata sharding. Shard the metadata DB by userId or workspace; this also localizes permission checks and change feeds.
• Garbage collection. Because chunks are shared via references, you can only delete a chunk when its reference count hits zero — do it with reference counting and a background sweep, never inline.
• Dedup scope. Cross-user dedup saves the most space but has privacy/security nuances; many systems dedup per-user or per-workspace as a safer default — mention the trade-off.
• Notification fan-out. For users on many devices, push change cursors rather than re-sending data, much like the read-optimized fan-out in Design Twitter.

FAQ

Why split files into chunks when designing Google Drive or Dropbox?

Chunking a file into fixed blocks (commonly around 4MB) enables resumable uploads, parallel transfer, and delta sync: when a file changes, only the modified chunks are re-uploaded instead of the whole file. Each chunk is content-addressed by its hash, which also makes block-level deduplication possible.

How does deduplication work in a cloud storage system?

Each chunk is hashed (e.g., SHA-256) and stored under that hash in blob storage. Before uploading, the client or server checks whether a chunk's hash already exists; if it does, it is not stored again - only a reference is recorded in metadata. Identical chunks across files and users are stored once, saving large amounts of space.

What is the difference between the metadata service and blob storage in Design Google Drive?

The metadata service holds the file system structure - file names, folder hierarchy, versions, permissions, and the ordered list of chunk hashes that make up each file - in a strongly consistent, indexed database. Blob storage holds the actual chunk bytes, content-addressed by hash, in a cheap, highly durable object store behind a CDN. Splitting them lets each scale and be consistent independently.

How do you handle sync conflicts in Dropbox-style storage?

Each file change is versioned. Clients watch for changes and pull updates; the server orders writes and detects when two clients edited the same version concurrently. Rather than silently overwriting, the system keeps both versions - typically creating a "conflicted copy" - so no data is lost, and lets the user reconcile.

Is a cloud storage system strongly or eventually consistent?

It is split. Metadata - permissions, file structure, version pointers - is kept strongly consistent so users never act on a stale view of who can access what. The bulk blob data and its propagation to other devices and regions is allowed to be eventually consistent, since a few seconds of sync delay is acceptable.