Design File Storage with Metadata, Access Control, and Chunked Uploads

Design a file-storage service with a drive-style user experience. Focus on the separation of file metadata from file bytes, access-control lists, and large-file uploads split into chunks. ### Constraints & Assumptions - Support authenticated users, file upload and download, and explicit sharing permissions. - A file can be large enough that an interrupted upload should resume without retransmitting every completed chunk. - Clarify overwrite/version behavior before choosing identifiers and commit semantics. - No scale target, availability SLA, or particular storage vendor is supplied. Describe a coherent baseline and identify where those requirements would change it. ### Clarifying Questions to Ask - Are permissions attached to individual files, inherited from folders, or both? - Is an overwrite a new immutable version or an in-place replacement? - May clients upload chunks directly to blob storage using scoped authorization? - What should happen to incomplete uploads and cached download links after access is revoked? ### Part 1 — Metadata and access control Define metadata records, file/blob identifiers, and permission checks for listing, sharing, and downloading. #### What This Part Should Cover - Separation of logical files, immutable content versions, and storage objects. - ACL entries and server-side authorization on relevant operations. - A consistent metadata view when content is uploaded or overwritten. ### Part 2 — Chunked upload and completion Describe upload-session creation, chunk transfer, retry/resume, and finalization. #### What This Part Should Cover - Chunk identity, size and integrity checks, and idempotent retry behavior. - A manifest or equivalent complete-file representation. - A commit boundary that exposes only a complete, validated version. - Cleanup of abandoned temporary chunks. ### Part 3 — Download and failures Walk through an authorized download and explain recovery from failures between blob writes and metadata commit. #### What This Part Should Cover - Authorization before granting access to bytes. - Range or chunk-based retrieval without making clients trust arbitrary storage keys. - Reconciliation for unreferenced blobs and incomplete metadata transitions. ```hint Decide when the file becomes visible Uploaded chunks can exist before the logical file is ready. Choose a single metadata transition that makes a complete version discoverable. ``` ### What a Strong Answer Covers - Metadata, ACL, upload, and download contracts that agree on file identity and visibility. - Resumable transfer without treating partial chunks as a finished file. - Explicit security and failure boundaries rather than an assumed transaction spanning every service. ### Follow-up Questions - How would two clients concurrently uploading a new version of the same file avoid silently overwriting each other's changes? - Which access-revocation guarantee is possible after a download URL has already been issued?