## Interview Prompt Design and implement an in-memory cloud storage service. It must add, inspect, and delete globally named files; list the largest files under a prefix; enforce per-user capacities; merge users; and back up or restore one user's files. Restoring skips a backed-up name if another user currently owns it. Merging a user transfers ownership and capacity, removes the merged user and that user's backup, and leaves the surviving user's prior backup unchanged. Explain the data model, operation semantics, and complexity of each API. ### Constraints & Assumptions - File names are globally unique and the system is entirely in memory. - The admin user has unlimited capacity; basic add-file calls act as admin operations. - Largest-file results sort by descending size and then lexicographic file name. - A backup is a snapshot of file names and sizes and is isolated from later mutations. ### Clarifying Questions to Ask - Should restore delete a user's current files before replaying the snapshot? - Does a skipped conflicting file consume capacity or change ownership? - What exactly is added when capacities and used storage are merged? ### What a Strong Answer Covers - A single authoritative file record with size and owner, plus per-user capacity and owned-name indexes. - Atomic validation-before-mutation for add, delete, merge, and restore operations. - Snapshot replacement semantics and conflict-aware restore without touching another user's files. - Deterministic prefix ranking and honest complexity trade-offs for scanning versus maintained indexes. ### Follow-up Questions - How would you make merge and restore safe under concurrent requests? - What changes if backups must survive process restarts? - How would you avoid copying a very large user's entire file map on every backup?