Loading system design…
Loading system design...
Design a cloud file storage and synchronisation service like Google Drive, Dropbox, or OneDrive. Users can upload, download, organise, share, and sync files across multiple devices — with version history, real-time sync, conflict resolution, and content deduplication.
| Metric | Value |
|---|---|
| Total users | 1 billion |
| Daily active users (DAU) | 200 million |
| Files stored | 2 trillion |
| Total storage | 500+ petabytes |
| Average file size | 250 KB (median); files up to 5 TB |
| File uploads per day | 2 billion |
| File downloads per day | 5 billion |
| Sync events per day | 50 billion (file edits, renames, moves, deletes across all devices) |
| Chunk size | 4 MB |
| Dedup savings | 40–60% of raw storage |
Upload files: users can upload files of any type and size (up to 5 TB per file) from web, desktop, or mobile clients
Download files: users can download any file they own or have been granted access to
File sync: changes made on one device (add, edit, rename, delete) automatically sync to all other devices with the user's account
File/folder organisation: hierarchical folder structure with create, rename, move, copy, and delete operations
File sharing: share files/folders with other users via email with granular permissions (viewer, commenter, editor); generate shareable links with optional expiry
Version history: maintain revisions of a file; users can view previous versions and restore any past version
Notifications: notify users when a shared file is edited, commented on, or when someone shares a new file with them
Offline access: users can mark files for offline availability; local changes sync when connectivity is restored (conflict resolution needed)
Search: full-text search across file names, content (for documents), and metadata (owner, type, modified date, shared with)
Storage quota: enforce per-user storage limits (e.g., 15 GB free, 100 GB / 2 TB paid tiers); track usage per user
Non-functional requirements define the system qualities critical to your users. Frame them as 'The system should be able to...' statements. These will guide your deep dives later.
Think about CAP theorem trade-offs, scalability limits, latency targets, durability guarantees, security requirements, fault tolerance, and compliance needs.
Frame NFRs for this specific system. 'Low latency search under 100ms' is far more valuable than just 'low latency'.
Add concrete numbers: 'P99 response time < 500ms', '99.9% availability', '10M DAU'. This drives architectural decisions.
Choose the 3-5 most critical NFRs. Every system should be 'scalable', but what makes THIS system's scaling uniquely challenging?
The complete explanation is included with Career and All Access. Compare it with your approach once you’ve worked through the problem.
Your system-design submission history is available after you sign in.
Sign In