"Once you understand the behavior of a Stack, you'll start noticing the same pattern across many different software systems."
In the previous article, we learned how to recognize Stack problems.
The important question wasn't:
"Does this application use a Stack?"
Instead, it was:
"Does this feature depend on the most recent action?"
When the answer is yes, the same architectural pattern appears across many different domains.
Let's explore those recurring patterns.
The Pattern Behind Most Stack-Based Designs
Although applications solve different business problems, many follow the same flow.
User Performs Action
↓
Remember Latest State
↓
User Requests Reverse
↓
Restore Previous State
The product changes.
The pattern stays the same.
That's why experienced engineers think in behaviors instead of applications.
Pattern 1: Document Editors
Imagine editing a report.
You perform these actions.
Type Text
↓
Insert Image
↓
Change Font
↓
Delete Paragraph
Now you press Undo.
The editor reverses only the latest action.
Delete Paragraph
↓
Change Font
↓
Insert Image
Each new action is remembered.
Each Undo restores the previous state.
Pattern 2: Browser Navigation
Consider a user browsing an e-commerce website.
Home
↓
Products
↓
Laptop
↓
Checkout
When the user presses Back, the browser doesn't restart the journey.
It returns to the most recently visited page.
Checkout
↓
Laptop
Every visited page becomes part of the navigation history.
Pattern 3: Multi-Step Forms
Many applications guide users through a sequence of screens.
Personal Details
↓
Address
↓
Payment
↓
Confirmation
If the user clicks Back, the application restores the previous step.
Each screen builds on the last one, making Stack behavior a natural fit.
Pattern 4: Nested Menus
Think about navigating application settings.
Settings
↓
Privacy
↓
Permissions
↓
Camera
Press Back.
Camera
↓
Permissions
Press Back again.
Permissions
↓
Privacy
The interface always returns to the most recently opened menu.
Pattern 5: Rollback in Business Workflows
Imagine an order-processing workflow.
Reserve Inventory
↓
Create Shipment
↓
Schedule Pickup
Suppose scheduling the pickup fails.
The application may need to reverse the completed work.
Undo
Schedule Pickup
↓
Undo
Create Shipment
↓
Undo
Reserve Inventory
Each completed step is reversed in the opposite order.
Pattern 6: Expression Evaluation
Programming languages also encounter Stack behavior.
Imagine evaluating nested expressions.
(
↓
(
↓
)
↓
)
The most recently opened expression must always be completed first.
Although the problem is technical rather than business-oriented, the underlying behavior is still the same.
The latest unfinished item is processed first.
Notice the Common Pattern
Every example we've explored follows the same idea.
Perform Action
↓
Remember Latest State
↓
Reverse Latest Action
Whether you're building a browser, a document editor, a workflow engine, or a programming language, the underlying design remains remarkably similar.
Thinking Like an Experienced Engineer
Beginners often memorize applications.
For example:
- Browsers use Stacks.
- Editors use Stacks.
- IDEs use Stacks.
Experienced engineers focus on behaviors instead.
They ask:
"Will users need to return to the previous state?"
or
"Must the latest operation be reversed first?"
If the answer is yes, they begin thinking about a Stack.
The business behavior drives the design.
How This Changes Your LLD Design
As applications become more complex, avoid spreading history management across multiple services.
Instead, isolate that responsibility.
Business Component
↓
History Manager
↓
Stack
↓
Undo / Rollback / Back
Each component focuses on one responsibility.
The business logic performs work.
The history manager remembers recent actions.
This separation produces designs that are easier to test, understand, and extend.
Common Beginner Mistakes
Mistake 1 — Memorizing Products Instead of Behaviors
Don't remember that browsers use Stacks.
Remember that moving back through recent history naturally leads to Stack behavior.
Mistake 2 — Assuming Every History Uses a Stack
Some history is chronological.
Some is searchable.
Some is analytical.
Only use a Stack when the latest item must always come first.
Mistake 3 — Mixing History With Business Logic
Undo tracking, navigation history, and rollback management deserve their own responsibility.
Avoid embedding them inside unrelated services.
Mistake 4 — Thinking Stacks Exist Only in User Interfaces
Stack behavior also appears in workflow engines, compilers, interpreters, transaction management, and many backend systems.
It's a general design pattern—not a UI feature.
Engineering Perspective
One of the biggest mindset shifts in software engineering is realizing that many completely different applications solve the same underlying problem.
Browsers, editors, transaction managers, and compilers may appear unrelated.
Yet they all need to answer the same question:
"What was the most recent unfinished or completed action?"
Once you recognize that behavior, Stack-based designs become easy to identify across domains.
The Most Important Insight
The value of a Stack isn't tied to any specific application.
Its real value lies in providing a simple, reliable way to remember and reverse the most recent actions.
That's why the same design pattern appears repeatedly in modern software systems.
One-Line Takeaway
Great engineers don't memorize where Stacks are used—they recognize the recurring behavior of remembering and reversing the most recent action.
Top comments (0)