# Design an In-Memory Object Manager with TTL Design and explain an in-memory object manager. Each object has a unique `object_id` and contains fields whose names are unique within that object. Support setting, getting, and deleting a field; deleting an object; scanning one object's fields by name prefix; writing a field with a start time and duration; removing fields that have expired by a requested time; and listing fields that are valid at a requested time. The reported prompt does not define which time an untimed get or prefix scan should observe after TTL-enabled fields exist. Identify that ambiguity before implementation. State an explicit clock policy or refine the affected API so every TTL-sensitive observation has a defined time; do not silently invent a rule and present it as part of the source. ### Constraints & Assumptions - Use a hash map of objects, with a second hash map for each object's fields. - Define the validity boundary for a timed write, including what happens exactly at its expiration time. - Explain how a later write, field deletion, or object deletion interacts with older expiration metadata. - A prefix scan must not match a field whose name is shorter than the prefix. - The source gives no required output encoding, ordering rule, or complexity target, so label any such choices as design assumptions. ### Clarifying Questions to Ask - Should ordinary get and prefix-scan operations accept an observation time, or use an injected clock? - Is a timed value valid on a half-open interval such as `[start_time, start_time + duration)`? - Must prefix-query results be sorted, and what should a missing field return? - Can a nonexpiring write replace a timed value, and can a timed write replace a nonexpiring value? ```hint Define time before state Make every TTL-sensitive read refer to an explicit observation time before choosing storage or cleanup structures. ``` ### What a Strong Answer Covers - Nested-map data structures for objects, fields, values, and expiration metadata. - Explicit semantics for timed validity, untimed observations, overwrites, deletion, and cleanup. - Correct CRUD and prefix-scan flows, including stale expiration records. - Complexity for direct lookup, scanning, sorting if chosen, and cleanup. - Boundary-focused tests for expiration, replacement, deletion, and prefix matching. ### Follow-up Questions 1. How would you make cleanup efficient if timed fields are numerous and cleanup is frequent? 2. How would you preserve deterministic behavior if the API used a real clock? 3. What synchronization would be required if multiple threads could update the same object?