File sync, storage & sharing

Design Google Drive

Medium

Store, sync, and share files across every device — chunk once, deduplicate globally, and never lose an edit.

Google Drive is a file storage, sync, and sharing platform: users upload files from any device, and those files appear — up to date — on every other device they own or share with. What makes it a systems problem rather than a CRUD app is the collision of three forces.

Files are large and mostly immutable — best stored as content-addressed chunks in blob storage, deduplicated globally so identical bytes are kept once.
The file tree, versions, and permissions are small but must stay strongly consistent — a separate metadata plane, sharded and transactional.
Every change must sync to a user's other devices in near-real-time — without re-uploading gigabytes on each edit.

The whole design is about splitting the metadata plane from the blob plane and getting three things right: chunked upload/download with dedup, delta sync with versioning and conflict resolution, and a sharing/permissions model that stays consistent.

Start by scoping. The interviewer wants to see you separate the metadata plane (the file tree, versions, and permissions — small, transactional, strongly consistent) from the blob plane (the file bytes — huge, immutable, content-addressed chunks in object storage). That split drives every later decision, and it lets sync move only changed chunks instead of whole files. Keep the functional list to the handful you'd actually build in 45 minutes — chunked upload/download, cross-device sync, sharing, and versioning — and fold the rest (folder ops, trash, offline reconcile) into those.

Functional

Upload and download files of any size, including multi-GB files, with resumable transfers.Includes the folder hierarchy (move/rename/delete) and a trash that supports restore.
Sync files and folders across a user's devices automatically and in near-real-time.A laptop change shows up on the phone within seconds; edits made offline reconcile on reconnect.
Share files/folders with other users or via link, with roles (viewer / commenter / editor).
Version history — every edit creates a new version; users can view and restore older versions.

Non-functional

Durability ~99.999999999% (11 nines) — an uploaded file must essentially never be lost.
High availability — 99.9%+ for reads/downloads; the service survives regional spikes.
Sync latency — a committed change propagates to other devices in < 5 s p99.
Scale — ~1B users, ~50 GB stored each → exabyte-class storage; ~100k peak change QPS.
Strong consistency on metadata — the file tree, version commits, and ACL changes (e.g. a revoked share) apply consistently, not eventually.

Out of scope

Real-time collaborative editing (Docs-style OT/CRDT)
Full-text search inside file contents
Media transcoding / thumbnail generation
Antivirus & DLP scanning

Check yourself· 3 questions

Question 1

Which architectural split most shapes this system and drives every later decision?

Question 2

Why store files as chunks rather than as whole blobs?

Question 3

Which non-functional requirement is the non-negotiable top priority for a storage product?