Design Add, Overwrite, Undo, and Redo for Billing State

# Design Add, Overwrite, Undo, and Redo for Billing State Design the core state model for a billing record that evolves through three feature stages: 1. Add a signed amount to the current amount. 2. Overwrite the current amount with an absolute value. 3. Undo and redo successful amount changes. The source does not specify whether history is local, persistent, or shared, so state your scope before choosing an implementation. Explain exact undo and redo semantics, behavior after a new change is made following an undo, money representation, error handling, complexity, and tests. If you propose an append-only log, distinguish the audit log from the user's current undo/redo cursor. ### Clarifying Questions to Ask - Is history maintained for one billing record, per user session, or globally? - Can amounts be negative, and which currency and precision rules apply? - Must undo survive process restarts and concurrent edits? - Does undo reverse only amount mutations, or also record creation and deletion? ### What a Strong Answer Covers - Exact semantics for additive and absolute commands. - Sufficient before/after state to reverse both command types. - Two-stack or history-cursor behavior, including redo invalidation after a branch. - Fixed-precision money, validation, and overflow boundaries. - Persistence and concurrency considerations kept separate from the in-memory core. - Tests for mixed commands, empty history, repeated undo/redo, and branching. ### Follow-up Questions - How would optimistic concurrency control prevent undoing someone else's newer change? - When is storing inverse commands unsafe compared with storing before and after values? - How would you compact a long persistent history without losing auditability?