"The biggest challenge in large software systems isn't storing information. It's finding the right information instantly."
By now we've established two important ideas.
First, data structures remain one of the most important building blocks of software design.
Second, experienced engineers don't begin with data structures—they begin by understanding the behaviour a system needs to optimise.
Now let's look at the first behaviour that appears almost everywhere in software engineering.
Fast lookup.
Whether you're designing Amazon, Uber, a banking application or a hospital management system, you'll encounter the same requirement again and again:
"Given an identifier, retrieve the corresponding information as quickly as possible."
It sounds simple.
But solving this efficiently is one of the reasons modern software scales.
Storing Data Is Easy. Finding It Isn't.
Suppose you're building a small bookstore application.
Initially, your system stores only five books.
Book 1
Book 2
Book 3
Book 4
Book 5
A customer wants to open Book 4.
The simplest solution is obvious.
Start at the beginning.
Check each book until you find the right one.
With only five books, this works perfectly.
No user notices any delay.
Now imagine your application becomes successful.
Instead of five books, you now have:
- 5,000 books
- 500,000 books
- 50 million books
The customer still asks exactly the same question.
"Show me Book #42,731."
Nothing changed from the user's perspective.
Everything changed for the system.
Searching one item after another no longer feels acceptable.
The problem was never storing millions of books.
The problem is finding one specific book quickly.
This Problem Exists Everywhere
Once you notice it, you'll see it in almost every software system.
Banking
A customer logs into their account.
Account Number
↓
Retrieve Account
↓
Display Balance
E-commerce
A customer clicks a product link.
Product ID
↓
Retrieve Product
↓
Show Product Page
Authentication
Every request sent by your browser includes a session identifier.
Session ID
↓
Retrieve Logged-in User
↓
Authorise Request
Ride Sharing
A ride request arrives.
The platform already knows the driver's identifier.
Driver ID
↓
Retrieve Driver
↓
Assign Ride
Hospital Management
A doctor searches for a patient.
Patient ID
↓
Retrieve Patient Record
↓
Continue Consultation
Different businesses.
Different domains.
Exactly the same engineering challenge.
Known Identifier
↓
Retrieve Matching Information
↓
Continue Processing
Why This Behaviour Deserves Special Attention
Notice something important.
The system already knows exactly what it's looking for.
It isn't searching randomly.
It isn't filtering thousands of possibilities.
It already has an identifier.
Its only responsibility is reaching the correct information as quickly as possible.
Because this behaviour happens so frequently, even tiny delays become expensive.
Imagine an application receiving one million requests every minute.
If every lookup becomes just slightly slower, users begin noticing.
Pages load later.
Requests take longer.
Servers perform more work.
Infrastructure costs increase.
Fast lookup isn't simply about speed.
It's about keeping an entire system responsive as traffic grows.
Fast Lookup Is a Behaviour, Not a Technology
One mistake beginners often make is thinking fast lookup refers to a particular programming language feature.
It doesn't.
It's a recurring engineering problem.
Whenever requirements sound like these:
- Find a customer using Customer ID.
- Retrieve an order using Order ID.
- Load a shopping cart.
- Fetch a session.
- Open a product page.
- Retrieve configuration by key.
You're seeing exactly the same behaviour.
The system knows what it wants.
It simply needs to reach it quickly.
Why This Matters During Low-Level Design
Imagine you're designing a hospital management system.
The requirement says:
"Doctors should be able to retrieve patient records instantly."
Notice what the requirement doesn't say.
It doesn't tell you:
- which classes to create,
- which programming language to use,
- which data structure to choose.
Those are implementation decisions.
The business only describes the behaviour.
Your responsibility as an engineer is to design a system that fulfils it efficiently.
That's why recognising behaviours is so important.
Before choosing a solution, you first need to recognise the engineering problem you're solving.
Weak Thinking vs Strong Thinking
Weak Thinking
I need a HashMap.
Strong Thinking
Users repeatedly retrieve information using unique identifiers.
This lookup dominates the workload.
The design should optimise fast retrieval.
Notice how implementation isn't mentioned until the behaviour is understood.
Common Beginner Mistakes
Mistake 1 — Believing storage is the challenge
Modern software rarely struggles to store information.
Retrieving it efficiently is often the harder problem.
Mistake 2 — Treating retrieval like any other operation
In many production systems, retrieval happens millions of times every day.
Optimising it has an enormous impact on user experience.
Mistake 3 — Jumping directly to implementation
Recognise the behaviour first.
Only then should you think about implementation.
Interview Perspective
Suppose an interviewer asks you to design a user management system.
A beginner immediately starts drawing classes.
A stronger candidate first asks questions like:
- How are users identified?
- Which operations happen most frequently?
- How many lookups happen every second?
- What should remain fast as the application scales?
These questions demonstrate engineering thinking.
Interviewers value this reasoning because it leads to better design decisions.
The Most Important Insight
Large software systems rarely become slow because they can't store enough information.
They become slow because finding the right information becomes increasingly expensive as data grows.
Fast lookup exists to solve that problem.
Understanding the problem is more important than memorising the solution.
One-Line Takeaway
Every large software system eventually faces the same challenge: finding one specific piece of information without searching through everything else.
Top comments (0)