# Design Extensible Undo and Redo for a Spreadsheet A spreadsheet already supports editing one cell and needs undo and redo. Extend the design to row and column deletion, dependent-cell recalculation, and operations that product policy says cannot be undone, without changing the core undo/redo engine for every new operation. ### Constraints & Assumptions - Undo followed by a new edit invalidates the redo branch. - Row and column deletion may touch many values and dependency edges. - The system should not snapshot the entire spreadsheet for every small edit. - Some operations are intentionally irreversible and must be signaled before execution. ### Clarifying Questions to Ask - Is collaborative editing in scope or is history local to one user? - Must history survive process restart? - Are formulas recalculated eagerly, lazily, or in a dependency transaction? ### Part 1 — Command model Define an operation interface and history structure that supports execute, undo, redo, and new operation types without conditionals in the history engine. #### What This Part Should Cover - Command or event objects with inverse data - Two-stack or cursor semantics - Atomicity and failure behavior ### Part 2 — Large and dependent edits Explain how row or column deletion stores enough information efficiently and how undo restores values, formulas, and dependency relationships. #### What This Part Should Cover - Sparse delta or persisted change set - Dependency graph ordering - Memory bounds, compaction, and checkpoints ### Part 3 — Product semantics Handle irreversible operations, history limits, and user-visible conflicts. #### What This Part Should Cover - Preflight and explicit confirmation - Why unsupported operations never enter reversible history - Clear status and recovery options ### What a Strong Answer Covers - An extensible interface - Correct dependency restoration - Bounded storage and explicit irreversible behavior ```hint Store the inverse, not a second implementation Each operation should produce or carry the exact data needed to invert itself. The history manager only moves operations between states. ``` ### Follow-up Questions - How would the design change for collaborative edits? - When should history be compacted into a checkpoint?