Define a File Store with User Quotas and Compression

Design the behavior and data model for a file-storage service with four groups of capabilities: adding, retrieving, and copying files; finding files whose names match a prefix and suffix; creating users with different storage capacities; and compressing or decompressing files. Propose a consistent API contract and explain the state changes and invariants needed to support these capabilities together. Define any behavior that is not specified rather than assuming a particular naming convention, compression ratio, or quota rule. ### Constraints and Clarifying Questions - Clarify whether file names are globally unique or scoped to a user, what retrieving a file returns, and how copying chooses ownership. - Define case sensitivity, whether prefix and suffix conditions are combined, and the order of search results. - Define which file size counts against capacity and what happens when an operation would exceed it. - Clarify whether compression changes a name or a representation flag, and how repeated compression or decompression is handled. - Focus on a coherent service contract and implementation model. No distributed deployment, numerical scale, or compression algorithm is prescribed. ### Part 1 — Add, Retrieve, and Copy Define file identity, the stored metadata, and the behavior of adding, retrieving, and copying files. Specify missing-source and destination-collision behavior and explain which state a failed operation may change. #### What This Part Should Cover - A precise namespace and the meaning of a file record. - Source lookup and destination validation for copying. - A consistent success/failure result with no partial file left after a failed operation. ### Part 2 — Search by Prefix and Suffix Define the matching contract and describe a baseline implementation. Explain how search relates to file identity and representation changes introduced by later features. #### What This Part Should Cover - Exact prefix/suffix semantics, including empty patterns and overlapping matches. - Deterministic result ordering and the metadata included in each result. - Search cost and the conditions under which an additional index would be justified. ### Part 3 — Enforce User Capacities Add users with different capacity limits. Explain how file ownership, copying, and used-space accounting interact, and how an operation fails when insufficient capacity is available. #### What This Part Should Cover - A per-user capacity invariant and the definition of used space. - Duplicate user IDs, unknown owners, and quota checks before committing a new file. - Atomic changes to the file records and the corresponding usage total. ### Part 4 — Compress and Decompress Define the representation state for compressed files and explain how both operations affect retrieval, copying, search, and capacity. Do not assume every file becomes smaller by a fixed factor. #### What This Part Should Cover - The metadata needed to distinguish representations and recover the original content. - Capacity validation when a representation grows, including decompression. - Repeated operations, conversion failures, and preservation of the prior file state when conversion does not commit. ```hint Revisit an earlier operation After introducing quotas and compression, run the copy operation again. Identify which owner, size, representation, and destination name it uses, and which checks must succeed together. ``` ### What a Strong Answer Covers - One consistent contract across all four capability groups. - File and capacity invariants that hold after successful and failed operations. - Concrete examples that expose interactions between copying, quotas, and representation changes. ### Follow-up Questions - If a user compresses a file and uses the freed capacity for another file, can decompression later fail? - If the payload store shares bytes between copies, should user usage follow physical deduplication or the declared per-file quota policy? - What additional coordination would be needed if two writes for the same user could execute concurrently?