System Design Interview
Cloud file storage and sharing platform supporting upload, download, sync, and collaboration for billions of files across devices.
Start with the bare minimum: a single server and database for metadata, plus blob storage for file bytes.
Add a CDN for fast global downloads, a load balancer as edge ingress, and rate limiting to protect the upload API.
Scale app servers behind a load balancer and add a metadata cache to absorb hot folder/permission reads.
Decouple post-upload work (thumbnails, virus scanning, search indexing) using a queue and workers so uploads stay fast.
Add DB replication, a versioning service for file history, and a notification service for multi-device sync.
Split files into chunks (e.g. 5–10 MB each) and upload them in parallel or sequentially. Each chunk is written to blob storage independently. A resumable upload session tracks which chunks have been received so a failed upload can resume from the last successful chunk rather than starting over.
Use optimistic concurrency — tag each file version with an ETag or version number. On write, the client sends the version it last saw; the server rejects the write if the current version doesn't match, forcing the client to fetch the latest and re-apply its changes. For collaborative editing, operational transformation or CRDTs handle fine-grained conflict resolution.
After every write, publish a change event to a notification service (e.g. via Server-Sent Events or WebSocket). Each connected device listens for events matching its user ID and re-fetches the changed metadata on receiving one. Delta sync — sending only the changed bytes — reduces bandwidth compared to re-downloading the full file.
Compute a content hash (e.g. SHA-256) of every chunk before storing it. Before writing a chunk to blob storage, check if an identical hash already exists. If it does, store only a pointer to the existing chunk. This is content-addressable storage — the same bytes are stored once regardless of how many users have uploaded identical files.
Store permissions as an Access Control List (ACL) in the metadata database — each entry maps a (file_id, user_id/group_id) pair to a role (owner, editor, commenter, viewer). Cache hot ACLs in Redis. On every file operation, check the calling user's role. Link-based sharing generates a signed URL or a token that encodes the permission level and expiry.
Shard when the primary metadata DB can no longer handle write throughput or when the dataset no longer fits on a single node. Shard by user_id so all of a user's files live on the same shard — this keeps folder-listing queries local and avoids cross-shard joins. Add routing logic in the application layer to map user_id to the correct shard.
Object storage like S3 or GCS stores at least 3 copies of every object across different availability zones by default. Durability is typically 11 nines (99.999999999%). For extra protection, enable cross-region replication so a regional outage doesn't make data unavailable. Version history means deleted or overwritten files can be recovered within a retention window.
After a file is uploaded, a worker indexes its name, MIME type, owner, and extracted text (for documents) into a dedicated search index like Elasticsearch. Queries run against the index rather than the metadata database. The index is updated asynchronously so it doesn't block uploads. Shard the index by user_id or org_id to keep queries isolated.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
