# Design a Multi-Level In-Memory Cloud Storage Service Design an in-memory cloud-storage service in four stages: file creation, deletion, and lookup; top-`n` file search by name prefix with a defined size-tie policy; users with storage capacities and user merging; and backup and restore that skips a filename currently owned by another user. Explain the data model, invariants, algorithms, and extension points while identifying source details that must be clarified. ### Constraints & Assumptions - The preserved source lists capabilities, not the exact command vocabulary or return sentinels. - File ownership and capacity accounting must remain consistent through deletion, merge, backup, and restore. - Restore skips names occupied by another user, but other snapshot and ownership interactions are unspecified. ### Clarifying Questions to Ask - What do create, delete, and lookup return on success, absence, or duplicate names? - Which direction does a user merge operate, and how are capacity and existing backups handled? - Does a backup replace an older snapshot, and what happens to snapshots when users merge? ```hint Centralize ownership Keep one authoritative filename record and derive user usage from the same mutations so later stages cannot drift. ``` ### What a Strong Answer Covers - File, owner, size, user-capacity, and backup representations. - Prefix top-`n` search with an explicitly supplied size and tie order. - Atomic capacity checks and well-defined user-merge behavior. - Restore conflict handling, snapshot semantics, complexity, and invariant tests. ### Follow-up Questions 1. Which indexes would improve prefix queries without making writes inconsistent? 2. How would concurrent operations change the design?