Design a file upload service similar to the core upload functionality of AWS S3 or Dropbox. Users upload files up to 10 GB, receive a unique file ID, and can generate shareable download links. The system serves 10 million users, handles 50,000 uploads per day, and must store files with 99.999999999% (11 nines) durability. Large uploads must be resumable -- users should not have to restart a 5 GB upload because of a network hiccup.
In your 90-second answer, cover: - Upload flow for large files: how chunking and resumability work - Separation of file metadata from blob storage - How shareable download links work (security and expiration) - Durability and availability guarantees
Constraints: uploads must complete within a time proportional to file size (no excessive overhead). A 1 GB file upload should not fail due to a single transient network error. Download links must be revocable.
How to approach it
- Hint 1
Large files should not be uploaded as a single HTTP request -- split them into chunks (5-10 MB each). The client uploads chunks independently, and the server reassembles them. If a chunk fails, only that chunk is retried, not the entire file.
- Hint 2
Store file metadata (filename, owner, size, permissions, chunk manifest) in a database, and the actual file bytes in object storage (S3, GCS). These scale very differently -- metadata is small and relational, blobs are large and write-once-read-many.
- Hint 3
Shareable links use pre-signed URLs: the server generates a URL containing a cryptographic signature, file ID, and expiration timestamp. The download service verifies the signature without any database lookup -- the URL itself is the proof of authorization.
Ready to answer it out loud?
Record your answer in 1:30 and Preptile scores it 1–10 with specifics — what landed, what you skipped, and what to say next time.
Practising needs an invite code. Join the waitlist and we’ll send you one.