"Not every software problem is about finding data or processing tasks. Some problems are about preserving the user's current context."
So far in this series, we've explored three different ways of thinking about data structures.
A HashMap helps us find information quickly.
A Heap helps us decide what should happen next based on priority.
A Queue helps us process work in arrival order.
Now let's look at a completely different kind of problem.
Imagine you're building an application where users perform a sequence of actions.
Sometimes they make mistakes.
Sometimes they change their minds.
Sometimes they simply want to go back to where they were a moment ago.
How should the system preserve that active working context?
This is where another fundamental data structure enters the picture—the Stack.
A Simple Example
Imagine you're editing a presentation.
You:
- add a new slide,
- insert an image,
- change the background,
- update the title.
Now you click Undo.
Which change should disappear?
Not the very first slide.
The application reverses the most recent change.
Click Undo again.
The previous change disappears.
The application keeps moving backward through the user's recent actions.
Another Everyday Example
Think about using a web browser.
You visit these pages.
Home
↓
Products
↓
Laptop
↓
Checkout
Now press the Back button.
Where should the browser take you?
Checkout
↓
Laptop
Press Back again.
Laptop
↓
Products
The browser preserves your recent navigation context, allowing you to retrace your steps naturally.
A Different Kind of Design Problem
Notice how different this is from the problems we've solved so far.
A HashMap asks:
Where is this object?
A Heap asks:
Which item has the highest priority?
A Queue asks:
Which task has been waiting the longest?
A Stack asks something entirely different.
What is the user's current working context?
Or, more practically:
What happened most recently?
That's a completely different business requirement.
Why Simpler Approaches Don't Work
Imagine storing user actions in a simple list.
Action 1
Action 2
Action 3
Action 4
Now someone presses Undo.
The application isn't interested in browsing the entire history.
It only needs one thing:
The latest action.
Searching through all previous actions every time would complicate the design unnecessarily.
The business requirement isn't to analyze history.
It's to preserve the current working context so recent actions can be revisited immediately.
The Mental Model
Imagine stacking books on your desk.
Book A
↓
Book B
↓
Book C
If you want Book A, you must first remove Book C.
Then Book B.
Only then can you reach Book A.
The most recently placed book is always the easiest to remove.
Many software systems naturally behave the same way.
Recognizing This Kind of Problem
Certain business requirements should immediately make you think about preserving recent context.
Examples include:
- Undo the last action
- Return to the previous page
- Cancel the latest operation
- Restore the previous screen
- Step back through a workflow
Notice the common theme.
Every example revolves around the latest user intent, not the oldest event.
How This Changes Your LLD Design
When designing a feature, don't immediately ask:
"Where should I store this information?"
Instead ask:
"Does this feature need to preserve the user's current working context?"
If the answer is yes, consider introducing a dedicated history component.
User Action
↓
History Manager
↓
Recent Action History
↓
Undo / Back
Instead of scattering temporary history across multiple classes, one component becomes responsible for managing recent actions.
That produces a cleaner and more maintainable design.
Common Beginner Mistakes
Mistake 1 — Treating Every History as Permanent
Some history exists only to support the current interaction.
Not every action needs to be stored permanently in a database.
Mistake 2 — Confusing Recent Context With Search
If the requirement is to search historical records, a Stack is probably not the answer.
Stacks are designed to preserve recent context, not provide historical queries.
Mistake 3 — Ignoring Reversal Order
Undo features work naturally only when actions are reversed in the opposite order from which they occurred.
That's the behavior a Stack supports.
Mistake 4 — Choosing a Stack Because There Is a Sequence
Many systems process sequences.
A Stack becomes useful only when the most recent action should always be revisited first.
Engineering Perspective
Experienced engineers don't simply hear the word history and think Stack.
Instead, they recognize requirements like:
- Undo the last change.
- Return to the previous screen.
- Restore the previous state.
- Cancel the latest operation.
These are all examples of preserving the user's active working context.
Once that behavior appears, a Stack often becomes the simplest and most natural solution.
The Most Important Insight
A Stack isn't designed to remember everything.
It's designed to preserve the current working context, making the most recent action immediately available whenever the user wants to move backward.
That's why Stack-based designs appear so frequently in modern software systems.
One-Line Takeaway
Great engineers don't use a Stack because it's LIFO—they use it when the business revolves around preserving and revisiting the user's most recent actions.
Top comments (0)