Extend a Key-Value Store with Commits and Explicit Rollover Semantics

Design a key-value store with `set`, `get`, and `delete`, then extend it with version-control-style `commit` and `rollover` operations. Explain the API, state representation, and behavior of each operation. ### Part 1 — Basic Key-Value Operations Define how keys and values are represented, what `get` returns for a missing key, and how `set` and `delete` affect the store. Explain the implementation and operation costs for a bounded baseline. #### What This Part Should Cover A coherent API with explicit missing-key and overwrite policies, state invariants, and a representation suited to the chosen scope. ### Part 2 — Commit and Rollover Explain how committed versions relate to the current working state. Clarify what the term `rollover` is intended to mean before defining its behavior. Discuss how a snapshot-and-restore interpretation could work, and what would change under another interpretation. #### What This Part Should Cover Stable version identity, preservation of committed state, deletion history, and explicit handling of uncommitted changes and invalid versions. Do not assume that rollover definitively means rollback. ### Constraints No persistence, distribution, concurrency, branching, or merge requirements are supplied. State which are in scope. The version-control analogy does not automatically require every feature of a full source-control platform. This is a design exercise with unresolved version semantics, not a single fixed executable contract. ### Clarifying Questions - Are values immutable, copied on assignment, or allowed to contain mutable objects? - Does commit snapshot the entire working state or record a delta? - Does rollover restore a version, start a new generation, or perform another operation? - What happens to uncommitted changes and later commits when selecting an earlier version? ```hint Preserve historical meaning A committed version should not silently change when the working store is updated later. ``` ### What a Strong Answer Covers - Correct basic store behavior and explicit API policies. - A conditional, internally consistent versioning model and its costs. - Snapshot isolation, deletion representation, and failure handling appropriate to the scope. ### Follow-up Questions - When would full snapshots become too expensive? - How would you distinguish a deleted key from a key whose value is null?