How do you design an Undo/Redo functionality? (Command Pattern)
Undo and Redo with the Command Pattern
I would represent each user operation as a Command containing the information required to execute and undo that operation. The application maintains an undo stack and a redo stack. Executing a new command pushes it onto the undo stack and clears the redo stack. Undo moves the command to the redo stack, while redo executes it again.
- 1
Command encapsulates an action and its inverse operation.
- 2
Undo and redo stacks maintain operation history.
- 3
A new command normally invalidates the redo history.
- 4
For complex applications, commands may need snapshots, event sourcing, or compensating operations.
- 5
Commands should consider transaction boundaries and failure handling.
Scenario Questions
0-2 years experience
- 1Imagine you're adding a simple text editor component that lets users type and delete characters. How would you implement an undo operation for a single character insertion using the command pattern?
- 2If the user presses Ctrl+Z twice after typing three words, what sequence of command objects should be executed and how would you manage the undo stack?
- 3What would happen if you forget to push a command onto the undo stack after executing it?
2-5 years experience
- 1We're building a diagram editor where users can move, resize, and delete shapes. How would you structure your command objects to support undo and redo, and what trade‑offs would you consider for grouping multiple actions into a single undo step?
- 2During testing we noticed that after a series of undo operations, the redo button sometimes re‑applies the wrong action. What could be causing this bug in the command‑stack implementation?
- 3If we need to limit memory usage for the undo history, what strategies would you use to prune or compress the command list without breaking redo functionality?
5-8 years experience
- 1Our collaborative whiteboard allows multiple users to edit the same canvas concurrently. How would you extend the command pattern to support per‑user undo/redo while ensuring consistency across the shared document?
- 2We have a large document with thousands of operations; undo/redo must stay responsive. What data structures or algorithms would you choose to keep the command history performant, and how would you handle long‑running commands?
- 3Suppose a command fails partway through (e.g., network error while saving a shape). How would you design the undo/redo system to maintain a consistent state in the presence of partial failures?
8+ years experience
- 1Our legacy codebase uses an ad‑hoc undo implementation scattered across modules. How would you plan a migration to a unified command‑pattern based undo/redo framework across the product line, considering backward compatibility and team coordination?
- 2When designing a platform‑wide undo/redo service that will be used by UI, CLI, and API clients, what architectural considerations (e.g., serialization of commands, versioning, distributed storage) would you prioritize?
- 3If we want to expose undo/redo as a first‑class feature in a microservices architecture, how would you handle command persistence, replayability, and eventual consistency across services?
Follow-up Questions
- What would you change if the commands needed to be persisted across application restarts?
- How would you handle undo for actions that involve external resources, like a file upload?
- Can you describe how you’d test the correctness of the redo stack after a series of mixed undo/redo operations?