# Design a Multi-Level Expiring Item Store Design a class with initialization, store, and retrieve operations for items placed into ordered storage levels. Retrieval examines levels from top to bottom. A level is eligible only while at least 50 percent of its capacity remains available, expired items cannot be returned, and among eligible items in the first usable level the heaviest item has priority. Define the API and data structures, then explain how expiration and repeated retrieval are handled. ### Constraints & Assumptions - Each item has a unique identifier, weight, insertion or expiry timestamp, and one assigned level. - Retrieving an item removes it from storage. - The 50 percent rule is evaluated using current occupied capacity and the level's configured capacity. - Ties in weight must use a deterministic rule chosen and documented by the candidate. ### Clarifying Questions to Ask - Does item capacity mean item count, total weight, or another unit? - Is expiry supplied as an absolute time or a time-to-live? - Should expired items be removed eagerly, lazily during retrieval, or by background cleanup? ```hint Order the predicates Write down which level is considered first and which item is preferred only after that level is chosen. ``` ```hint Make time testable Inject a clock or pass the current time so expiry tests do not wait on wall-clock time. ``` ### What a Strong Answer Covers - Clear class boundaries and invariants for levels, items, capacity, and time. - A retrieval algorithm that applies level order, capacity eligibility, expiry, and weight in the stated order. - A testable clock abstraction and deterministic tie-breaking. - Complexity, cleanup strategy, concurrency behavior, and representative tests. ### Follow-up Questions - How would retrieval change if the heaviest eligible item across all levels were required? - How would you make store and retrieve safe under concurrent calls?