Memento pattern in LLD - System Design Exercise

Design: Memento Pattern Implementation

Design the core components of the Memento pattern including Originator, Memento, and Caretaker. Out of scope are UI undo/redo integration and persistence of states beyond runtime.

Functional Requirements

FR1: Allow an object to save its state at a point in time.

FR2: Enable restoring the object to a previous saved state.

FR3: Keep the saved state separate from the object's main logic.

FR4: Support multiple saved states for undo functionality.

FR5: Ensure the saved states are immutable once created.

Non-Functional Requirements

NFR1: The system should handle up to 1000 saved states per object.

NFR2: Restoring a state should happen within 10 milliseconds.

NFR3: Memory usage should be optimized to avoid storing full copies if possible.

NFR4: The design should keep the originator's internal state encapsulated.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Originator: the object whose state is saved and restored

Memento: the object that stores the saved state

Caretaker: manages saved states and controls undo/redo

State storage mechanism: in-memory list or stack

Design Patterns

Command pattern for undo/redo operations

Prototype pattern for cloning state

Flyweight pattern to optimize memory for repeated state parts

Reference Architecture

Originator <--> Memento
Caretaker manages Memento stack

+------------+       +------------+       +------------+
| Originator |<----->|  Memento   |<----->| Caretaker  |
+------------+       +------------+       +------------+

Components

Originator

Any OO language

Creates a memento containing a snapshot of its current internal state and uses mementos to restore its state.

Memento

Immutable object

Stores the internal state of the Originator. It is immutable and only accessible by the Originator.

Caretaker

In-memory stack or list

Keeps track of saved mementos and provides undo/redo functionality by restoring states.

Request Flow

1. 1. Originator creates a Memento capturing its current state.

2. 2. Caretaker receives and stores the Memento in a stack.

3. 3. When undo is requested, Caretaker retrieves the last Memento.

4. 4. Originator restores its state from the retrieved Memento.

5. 5. Repeat for multiple undo steps as needed.

Database Schema

Not applicable as this pattern typically uses in-memory objects. Key entities: Originator (has state), Memento (stores snapshot), Caretaker (manages Memento collection).

Scaling Discussion

Bottlenecks

Memory usage grows linearly with number of saved states.

Restoring large complex states may cause latency spikes.

Managing many saved states can slow down undo/redo operations.

Solutions

Use incremental or differential snapshots to save only changes between states.

Limit the number of saved states with a fixed-size stack or pruning strategy.

Compress or serialize states efficiently to reduce memory footprint.

Use lazy restoration or background processing for heavy state restores.

Interview Tips

Time: Spend 10 minutes explaining the pattern and components, 15 minutes designing the interaction and data flow, 5 minutes discussing scaling and optimizations, and 5 minutes for questions.

Explain separation of concerns: Originator vs Memento vs Caretaker.

Highlight immutability of Memento to protect state integrity.

Discuss how this pattern supports undo functionality.

Mention memory and performance considerations.

Show understanding of when and why to use this pattern.