"Finding something quickly and finding the best thing quickly are two completely different engineering problems."
So far in this series, we've explored one of the most common behaviours in software systems:
Fast lookup.
Whenever a system already knows what it's looking for—a User ID, Product ID, Order ID or Session ID—a HashMap becomes an excellent choice.
But not every software problem works this way.
Imagine you're building a ride-sharing application.
A rider requests a cab.
The system doesn't already know which driver to assign.
Instead, it must answer a different question:
"Out of all available drivers, who is the best choice?"
Now consider a task scheduler.
Hundreds of jobs are waiting to run.
The scheduler doesn't ask:
"Find Job #123."
It asks:
"Which job should run next?"
Or imagine a gaming platform.
Thousands of players are competing.
Nobody asks:
"Find Player ID 1057."
Instead, users ask:
"Who are the top 10 players?"
These problems are fundamentally different from fast lookup.
They're not about finding a specific object.
They're about finding the best object according to some priority.
This shift in thinking introduces another important design behaviour.
Fast Lookup vs Best Selection
Let's compare two different requirements.
Requirement 1
Customer ID = 1052
↓
Retrieve Customer
The system already knows exactly what it needs.
The challenge is retrieving it efficiently.
Requirement 2
Available Drivers
↓
Find Nearest Driver
↓
Assign Ride
The system doesn't know the answer yet.
It must compare multiple candidates before making a decision.
These two behaviours may look similar.
In reality, they solve completely different engineering problems.
Every Software System Doesn't Search the Same Way
Consider these questions.
Find Order #50231
versus
Find the highest priority order.
Or:
Retrieve Product ID = P1042
versus
Recommend the most popular product.
Or:
Find Employee ID = 2107
versus
Find the employee with the highest sales this month.
The first question always provides an identifier.
The second question requires comparison.
That distinction changes everything.
Understanding Priority
Let's imagine a hospital emergency room.
Five patients arrive.
Patient A
Minor injury
Patient B
High fever
Patient C
Heart attack
Patient D
Broken arm
Patient E
Cold
If patients are treated simply in the order they arrived, the result may look like this.
Arrival Order
↓
Patient A
↓
Patient B
↓
Patient C
Technically, this is fair.
But medically, it is dangerous.
Instead, hospitals work differently.
All Patients
↓
Evaluate Severity
↓
Treat Most Critical Patient First
Notice what happened.
The hospital isn't searching for a specific patient.
It is selecting the patient with the highest priority.
Many software systems solve exactly this kind of problem.
Priority Exists Everywhere
Once you begin recognising it, you'll see priority-based behaviour in almost every application.
Ride Sharing
Available Drivers
↓
Nearest Driver
↓
Assign Ride
The goal is not to retrieve a particular driver.
The goal is to choose the best one.
Operating Systems
Your computer may have dozens of applications running.
Running Processes
↓
Choose Next Process
↓
CPU Executes
The operating system continuously decides which task deserves the processor next.
Banking
Imagine thousands of payment requests.
Some are ordinary transfers.
Others involve fraud detection.
Incoming Requests
↓
Highest Priority Investigation
↓
Fraud Team
The system focuses first on the most urgent cases.
Customer Support
An e-commerce company receives thousands of tickets.
Support Tickets
↓
Highest Severity
↓
Support Agent
Critical production issues should not wait behind password reset requests.
Online Gaming
Players finish a tournament.
All Scores
↓
Highest Scores
↓
Leaderboard
The platform doesn't display everyone equally.
It highlights the best performers.
Why a List Isn't Enough
Suppose you're storing player scores.
90
75
82
98
66
95
A user asks:
"Who is currently leading?"
One approach is to inspect every score.
Check 90
↓
Check 75
↓
Check 82
↓
Check 98
↓
Highest Score Found
This works.
But imagine millions of players updating their scores every second.
Repeating this process over and over becomes expensive.
The challenge isn't storing scores.
The challenge is identifying the best score efficiently.
This Is a Different Behaviour
Let's compare the behaviours we've learned so far.
Behaviour 1
Known Identifier
↓
Retrieve Information
Examples:
- User ID
- Order ID
- Product ID
Behaviour 2
Many Candidates
↓
Compare Priority
↓
Choose Best Candidate
Examples:
- Nearest driver
- Highest score
- Highest priority task
- Most urgent patient
Both behaviours are common.
Neither replaces the other.
They solve different engineering problems.
How Experienced Engineers Think
Suppose you're designing a food delivery platform.
A new order arrives.
A beginner might immediately think:
"How do I store delivery partners?"
An experienced engineer asks a different question.
"How does the system decide which delivery partner should receive this order?"
Notice the difference.
One question is about storage.
The other is about decision making.
Software design becomes much easier when you recognise the behaviour before thinking about implementation.
Weak Thinking vs Strong Thinking
Weak Thinking
I need to store drivers.
Strong Thinking
The system repeatedly chooses the most suitable driver.
This is a priority-selection problem.
Weak Thinking
Every search problem is the same.
Strong Thinking
Finding a known object and selecting the best object are different engineering behaviours.
Common Beginner Mistakes
Mistake 1 — Treating every problem as a lookup problem
Many beginners assume every search involves finding a specific object.
In reality, many systems need to rank or prioritise multiple candidates.
Mistake 2 — Ignoring business rules
The "best" option depends on the business.
For a ride-sharing app, it might mean the nearest driver.
For a scheduler, it might mean the highest priority task.
For a hospital, it means the most critical patient.
Always understand how the business defines "best."
Mistake 3 — Thinking priority is fixed
Priority often changes over time.
A support ticket may become more urgent.
A player's score changes.
A driver's location changes.
Good systems continuously adapt to changing priorities.
Mistake 4 — Jumping to implementation
Before asking:
"Which data structure should I use?"
first ask:
"How is the system deciding what is best?"
That question naturally leads to the right solution.
Interview Perspective
Suppose an interviewer asks:
Design a job scheduler.
A weaker candidate may immediately start creating classes.
A stronger candidate first identifies the core behaviour.
"The scheduler repeatedly chooses the highest-priority job from many waiting jobs. The main challenge is efficient priority selection, not simple lookup."
This demonstrates that you understand the engineering problem before discussing implementation.
Interviewers value this way of thinking because real software design starts with recognising behaviours.
The Most Important Insight
Not every system knows exactly what it is looking for.
Sometimes the system must evaluate many possible choices and select the one that best satisfies the current business rule.
Recognising this distinction is the first step toward understanding priority-based systems.
One-Line Takeaway
Fast lookup answers "Where is it?" Priority systems answer "Which one should happen next?"
Top comments (0)