"A Stack isn't designed to store data. It's designed to make the most recent piece of work the easiest to access."
In the previous article, we discovered a new kind of design problem.
Some systems don't need to find the fastest item.
Some don't need to process tasks in arrival order.
Instead, they need to work with whatever happened most recently.
That's exactly the problem a Stack solves.
In this article, we'll understand how a Stack works and why its behavior appears naturally in many software systems.
Imagine a Stack of Plates
Think about a stack of dinner plates.
Plate 4
──────────
Plate 3
──────────
Plate 2
──────────
Plate 1
──────────
When you need a plate, which one do you take?
The one on the top.
You don't pull out the bottom plate.
Likewise, when placing a new plate, you put it on top.
This simple rule defines the behavior of a Stack.
What Is a Stack?
A Stack is a data structure where both insertion and removal happen from the same end.
The last item added is always the first one removed.
This behavior is called LIFO (Last In, First Out).
Push A
↓
Push B
↓
Push C
↓
Pop
↓
C
Notice something important.
A Stack isn't trying to preserve arrival order like a Queue.
Instead, it preserves recency.
The newest item is always the easiest to access.
Every Data Structure Solves a Different Design Problem
By now, we've seen several data structures, each answering a different question.
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:
What happened most recently?
Choosing the right data structure begins with identifying which of these questions your system needs to answer.
Push and Pop
Stacks are built around two simple operations.
Push
Adding a new item.
Before
Top
↓
B
↓
A
Push C
After
Top
↓
C
↓
B
↓
A
Pop
Removing the most recent item.
Before
Top
↓
C
↓
B
↓
A
Pop
After
Top
↓
B
↓
A
Only the top item is removed.
Everything below remains untouched.
Real-World Example: Browser History
Imagine browsing an online shopping website.
Home
↓
Electronics
↓
Laptops
↓
Gaming Laptop
When you press Back, the browser returns to the page you visited most recently.
Gaming Laptop
↓
Laptops
It doesn't jump to the homepage.
The browsing history behaves like a Stack.
Each new page is pushed.
Each Back operation pops the latest page.
Real-World Example: Undo
Suppose you're editing a document.
You:
- type a sentence,
- insert an image,
- change the title,
- delete a paragraph.
Now you press Undo.
Which action should disappear?
The deleted paragraph.
Press Undo again.
The title change disappears.
Every Undo reverses the latest modification first.
That's another Stack.
Why This Behavior Matters
Notice something common across these examples.
The system isn't interested in:
- the oldest action,
- every action,
- or searching through history.
It only cares about the latest unfinished action.
That's why a Stack is such a natural fit.
How This Changes Your LLD Design
When a feature depends on reversing recent operations, don't scatter history across multiple classes.
Instead, create a dedicated component responsible for managing recent actions.
User Action
↓
History Stack
↓
Undo Request
↓
Restore Previous State
The feature becomes easier to understand because one component owns one responsibility.
Common Beginner Mistakes
Mistake 1 — Thinking a Stack Is Just Another List
A list allows access from anywhere.
A Stack intentionally restricts access to one end because that's what the business behavior requires.
Mistake 2 — Using a Stack for Searching
Stacks are excellent for recent history.
They are poor choices when the primary requirement is searching or random access.
Mistake 3 — Forgetting That Order Matters
A Stack works correctly only when the newest item should always be processed first.
If the oldest item should be processed first, a Queue is the better choice.
Mistake 4 — Treating LIFO as the Goal
LIFO isn't the reason to choose a Stack.
It's simply the consequence of solving a business problem centered on recent actions.
Engineering Perspective
Experienced engineers rarely say:
"Let's use a Stack."
Instead, they recognize behaviors like:
- Undo
- Back
- Reverse the latest change
- Restore the previous state
Once those behaviors appear, the Stack becomes an obvious design choice.
The data structure follows the business requirement—not the other way around.
The Most Important Insight
A Stack exists because many software systems naturally revolve around the most recent action.
Understanding that behavior is much more valuable than memorizing the term Last In, First Out.
One-Line Takeaway
A Stack isn't about storing data on top—it's about making the most recent action the easiest one to revisit.
Top comments (0)