“The best software engineers don’t begin by choosing data structures. They begin by understanding what the system needs to do.”
In the previous article, we learned that data structures never stopped being important after DSA.
Their role simply changed.
During coding interviews, we often ask ourselves:
“Which data structure will solve this problem efficiently?”
In Low-Level Design, experienced engineers ask a different question:
“What behaviour should this system optimise?”
At first glance, these questions sound similar.
In reality, they lead to completely different ways of thinking.
This article is about understanding why behaviour—not implementation—is where every good design begins.
Why Beginners Often Think About Data Structures Too Early
Imagine someone asks you to design an online food delivery platform.
Many beginners immediately start thinking:
- Should I use a HashMap?
- Will I need a Queue?
- Should I store everything in a Tree?
- Would a Graph be useful?
These aren’t bad questions.
They’re simply being asked too early.
Before choosing any data structure, we need to understand what the system is actually expected to do.
Software engineering isn’t about selecting tools first.
It’s about understanding problems first.
Every Software System Is Really a Collection of Behaviours
Let’s consider a food delivery application.
From a user’s perspective, it looks like this.
Customer Places Order
│
Restaurant Accepts
│
Assign Delivery Partner
│
Track Delivery
│
Order Delivered
Enter fullscreen mode Exit fullscreen mode
It looks like one workflow.
But an engineer sees something very different.
Each step represents a different behaviour.
Let’s break them apart.
Behaviour 1 — Retrieve Existing Information
A customer opens an order they placed yesterday.
Customer
↓
Order ID
↓
Retrieve Order
Enter fullscreen mode Exit fullscreen mode
The system already knows exactly which order it needs.
The challenge is retrieving it quickly.
Behaviour 2 — Choose the Best Candidate
A restaurant has multiple delivery partners nearby.
Available Drivers
↓
Choose Best Driver
↓
Assign Ride
Enter fullscreen mode Exit fullscreen mode
This isn’t simply finding any driver.
The system must identify the most suitable one.
Behaviour 3 — Process Work Later
A customer uploads a profile picture.
The user shouldn’t have to wait while the application resizes images, generates thumbnails and stores multiple versions.
Instead, the application acknowledges the upload immediately.
Image Uploaded
↓
Accept Request
↓
Background Processing
Enter fullscreen mode Exit fullscreen mode
The important behaviour isn’t retrieval.
It’s processing work asynchronously.
Behaviour 4 — Help Users Search
A customer begins typing:
Piz...
Enter fullscreen mode Exit fullscreen mode
The application immediately suggests:
- Pizza Hut
- Pizza Express
- Pizza Corner
The behaviour isn’t exact matching.
It’s intelligent searching while the user is still typing.
Behaviour 5 — Explore Relationships
Imagine a professional networking platform.
A recruiter opens someone’s profile and wants to see mutual connections.
Recruiter
↓
Candidate
↓
Mutual Connections
Enter fullscreen mode Exit fullscreen mode
The challenge is understanding how different people are connected.
One Application. Many Different Behaviours.
Notice something interesting.
We’re still talking about the same application.
We didn’t change the business domain.
We only changed the behaviour.
Food Delivery Platform
│
┌────────────────┼────────────────┐
│ │ │
Retrieve Data Process Work Search Suggestions
│ │ │
Different Need Different Need Different Need
Enter fullscreen mode Exit fullscreen mode
Every behaviour creates a different engineering problem.
And different engineering problems naturally lead to different design decisions.
This is one of the biggest mindset shifts in Low-Level Design.
Applications are not collections of classes.
They’re collections of behaviours.
Why Behaviour Comes Before Implementation
Suppose two engineers are designing Amazon.
Engineer A
Says:
Let's use a HashMap.
Enter fullscreen mode Exit fullscreen mode
Engineer B
Says:
Customers retrieve products using Product IDs millions of times every day.
That operation must remain extremely fast.
Enter fullscreen mode Exit fullscreen mode
Which explanation sounds more like engineering?
The second one.
Because it starts with the problem.
The data structure is simply one possible solution.
Experienced engineers rarely discuss implementation before understanding behaviour.
Behaviour Drives Every Engineering Decision
Consider an online banking application.
Customers can:
- Check balances
- Transfer money
- Download statements
- View transaction history
- Update account information
Should every operation receive the same amount of optimisation?
Probably not.
Checking an account balance may happen millions of times every day.
Downloading an annual statement happens much less frequently.
Good engineers recognise this difference.
They spend more effort optimising what users experience most often.
Understanding behaviour helps us decide where our engineering effort should go.
Real Systems Hide These Behaviours Everywhere
Once you begin thinking this way, you’ll notice these behaviours in almost every application.
Ride Sharing
Open Driver Profile
↓
Retrieve Driver Information
Enter fullscreen mode Exit fullscreen mode
Video Streaming
Video Uploaded
↓
Encoding
↓
Thumbnail Generation
↓
Notification
Enter fullscreen mode Exit fullscreen mode
Banking
Incoming Transactions
↓
Identify Highest Priority Fraud Case
Enter fullscreen mode Exit fullscreen mode
Navigation Systems
Current Location
↓
Connected Roads
↓
Destination
Enter fullscreen mode Exit fullscreen mode
E-commerce
User Types
"Sam..."
↓
Suggested Products
Enter fullscreen mode Exit fullscreen mode
Different industries.
Different products.
The underlying behaviours are surprisingly similar.
That’s why experienced engineers learn to recognise behaviours before they think about implementation.
Weak Thinking vs Strong Thinking
Weak Thinking
I know HashMaps are fast.
I'll use one.
Enter fullscreen mode Exit fullscreen mode
Strong Thinking
Users repeatedly retrieve products using Product IDs.
Fast retrieval directly affects user experience.
The system should optimise that behaviour.
Enter fullscreen mode Exit fullscreen mode
Weak Thinking
Queues are useful.
Let's add one.
Enter fullscreen mode Exit fullscreen mode
Strong Thinking
Image processing takes several seconds.
Users shouldn't wait.
This work should happen in the background.
Enter fullscreen mode Exit fullscreen mode
Notice how experienced engineers always explain the problem before they discuss the solution.
Common Beginner Mistakes
Mistake 1 — Starting with implementation
Many beginners ask:
“Which data structure should I use?”
before they’ve fully understood the problem.
Always understand the behaviour first.
Mistake 2 — Treating every operation equally
Not every operation deserves the same optimisation.
Identify what users do most often.
Optimise that first.
Mistake 3 — Thinking features instead of behaviours
Features describe what users see.
Behaviours describe what engineers must optimise.
The distinction matters.
Mistake 4 — Assuming one application uses one data structure
Real applications use many different data structures because they solve many different kinds of problems.
Interview Perspective
Imagine an interviewer asks:
Design a movie ticket booking system.
A beginner immediately starts creating classes.
A stronger candidate begins by understanding behaviours.
They ask questions like:
- Which operations happen most frequently?
- Which actions must feel instantaneous?
- Which work can happen asynchronously?
- Which requests become expensive as traffic grows?
- Which parts of the system will users interact with the most?
These questions demonstrate engineering maturity.
Interviewers often value this reasoning more than immediately selecting the “correct” data structure.
The Most Important Insight
Data structures don’t exist because software engineers wanted more ways to store information.
They exist because software systems repeatedly encounter different behaviours that need to be optimised.
Recognising those behaviours is one of the most valuable skills an engineer can develop.
Once the behaviour is clear, the implementation becomes much easier to choose.
One-Line Takeaway
Great software engineers don’t begin with data structures. They begin by understanding the behaviour the system needs to optimise.
답글 남기기