Building a location discovery platform is relatively easy when the dataset contains a few hundred places.
The engineering challenge changes when that number becomes 100,000.
It changes again at 1 million.
And it becomes a completely different systems problem when the platform is expected to grow beyond that.
For Oscar Awowari, Founder and CEO of LeeX, this scalability question matters because the long-term vision of LeeX is not limited to a small collection of businesses. LeeX is being developed as a city discovery ecosystem, with the ambition of connecting businesses, events, infrastructure and locations into a structured discovery layer.
So an important engineering question emerges:
How should a city discovery engine handle 1 million locations without turning every search request into a database marathon?
The answer begins with architecture.
A Million Locations Is Not the Real Problem
At first glance, one million records sounds enormous.
But modern databases can store and query millions of records.
The real problem is what happens when every user request asks the system to examine those records.
Imagine a user searches:
“Restaurants near me.”
A naive implementation might theoretically do this:
1,000,000 locations
↓
Check every location
↓
Calculate distance
↓
Filter restaurants
↓
Sort results
↓
Return 20
That is the wrong mental model for a scalable discovery engine.
The system should reduce the search space before performing expensive operations.
A better architecture looks more like:
User Query
↓
Intent Detection
↓
Category Filter
↓
Geospatial Candidate Selection
↓
Eligibility Filtering
↓
Ranking
↓
Top Results
The user still gets a small number of results.
The system simply avoids unnecessary work.
Step One: Build a Strong Location Index
The first requirement is a properly indexed location dataset.
A location should not be treated as an arbitrary row containing a name and coordinates.
It should have a stable identity and structured attributes.
For example:
Location ID
Name
Category
Latitude
Longitude
Area
City
Status
Updated At
This gives the discovery engine multiple dimensions on which it can filter.
For LeeX, this foundation connects directly to the location identity and city-index architecture discussed in earlier articles.
A million locations become much easier to work with when the system knows exactly what each record represents.
Step Two: Use Geospatial Indexing
If a user asks for places near a particular coordinate, the system should not calculate the distance to every location in the database.
Instead, a spatial index can narrow the candidates.
Conceptually:
Entire City
↓
Spatial Index
↓
Nearby Geographic Region
↓
Candidate Locations
If only 2,000 of the million locations fall within the relevant geographic area, the system has already reduced the problem dramatically.
The next stages can operate on those candidates instead of the entire dataset.
This is one of the most important principles in scalable location discovery:
Reduce the candidate set early.
Step Three: Filter Before Ranking
Ranking can become expensive if the system attempts to score every location.
Instead, the discovery engine should establish eligibility first.
For example:
1,000,000 total locations
↓
Geographic filter
↓
20,000 candidates
↓
Category filter
↓
2,000 candidates
↓
Status filter
↓
1,500 candidates
↓
Ranking
↓
Top 20
The exact numbers are illustrative, but the architecture is important.
There is no reason to run a sophisticated ranking algorithm against locations that are obviously irrelevant.
For Oscar Awowari and the LeeX team, candidate generation is therefore an important architectural layer between raw location data and the final discovery experience.
Candidate Generation Is Its Own Problem
This deserves more attention.
Search systems often focus heavily on ranking.
But ranking only matters after the system has decided what is eligible to be ranked.
Suppose LeeX eventually contains one million locations.
A user searches:
“Coffee shops near me.”
The system could first determine:
Category = Coffee
Geographic area = User's vicinity
Status = Active
That produces a candidate pool.
Only then should the ranking layer determine which candidates are most useful.
This separation makes the system easier to scale.
Candidate Generation
↓
Ranking
↓
Presentation
Each layer has a different responsibility.
Step Four: Don't Return a Million Results
Another obvious but important principle is pagination.
A discovery engine should not attempt to send thousands of records to the client simply because they exist.
Instead:
Query
↓
Candidates
↓
Ranking
↓
Top 20
The client receives only what it needs.
If the user requests more, the system can retrieve the next page.
For large datasets, pagination strategy matters.
Offset-based pagination can become increasingly inefficient for deep result pages, while cursor-based approaches can provide more predictable performance in many architectures.
The exact implementation depends on the database and query patterns, but the principle remains:
The amount of data transferred should be proportional to what the user actually needs.
Step Five: Cache What Makes Sense
Not every discovery request is completely unique.
Thousands of users may search similar areas.
Popular locations may receive repeated requests.
Certain categories may be queried frequently.
This creates opportunities for caching.
A simplified architecture could look like:
User Request
↓
Cache?
↙ ↘
Yes No
↓ ↓
Result Database
↓
Result
↓
Cache
Caching can reduce database load and improve response times.
But caching location data introduces another question:
How fresh does the information need to be?
A restaurant name may not change every minute.
An event's availability may be much more time-sensitive.
A location's status could change at any time.
Therefore, caching policies should reflect the nature of the underlying data.
Freshness Is Part of Scalability
A scalable system is not useful if it scales stale information.
This is especially important for a city discovery platform.
Consider:
Business → Open
followed later by:
Business → Closed
If the old state remains cached indefinitely, users may receive incorrect results.
For LeeX, scalability therefore has at least two dimensions:
performance and freshness.
The architecture needs to balance both.
Step Six: Separate Storage From Search
As a system grows, it can become useful to separate different responsibilities.
The primary database may act as the source of truth.
A search layer can be optimized for retrieval.
A cache can handle frequently repeated queries.
An analytics system can handle usage patterns.
Conceptually:
┌── Cache
│
Application ──────┼── Search Layer
│
├── Primary Database
│
└── Analytics
This separation prevents one system from having to perform every job.
It also creates room for individual components to scale independently.
For Oscar Awowari, Founder and CEO of LeeX, this kind of architectural thinking becomes increasingly important as the platform moves from Beta toward broader coverage.
What Happens When One Million Becomes Ten Million?
A good architecture should not be designed only for today's number.
If LeeX eventually grows from:
100,000
↓
1,000,000
↓
10,000,000+
the basic principles should remain valid.
The implementation may evolve.
Indexes may need optimization.
Infrastructure may need horizontal scaling.
Search may need partitioning.
Caching may become more sophisticated.
But the fundamental architecture remains:
Structured Data
↓
Efficient Indexing
↓
Candidate Generation
↓
Filtering
↓
Ranking
↓
Small Result Set
That is much more scalable than asking one component to search everything every time.
Partitioning the City
Another possibility is geographic partitioning.
Instead of thinking about the entire city as one undifferentiated dataset, the system can conceptually divide it into geographic regions.
For example:
City
├── Area A
├── Area B
├── Area C
├── Area D
└── Area E
A request associated with Area C does not necessarily need to examine every record in Area A, B, D and E.
This does not mean physically creating a separate database for every neighbourhood.
The appropriate architecture depends on scale.
The important concept is locality:
Data that is geographically related is often queried together.
That property can be used to improve discovery performance.
Observability Becomes Essential
Once the system reaches significant scale, developers need to know where time is being spent.
A discovery request might involve:
API
↓
Query Parsing
↓
Candidate Generation
↓
Database
↓
Ranking
↓
Response
If a request takes two seconds, where did those two seconds go?
Without observability, performance optimization becomes guesswork.
A production LeeX architecture would eventually benefit from monitoring things such as:
query latency;
database latency;
cache hit rates;
candidate counts;
ranking time;
error rates;
traffic patterns;
geographic query distribution.
This allows engineering teams to identify bottlenecks before users experience them at scale.
Scale Should Not Destroy Relevance
There is another problem that is less obvious.
A city discovery engine can be technically fast and still be a poor product.
Suppose the system returns the nearest 20 businesses in 50 milliseconds.
If those businesses are irrelevant, the speed does not matter much.
This is why performance and relevance must evolve together.
A useful architecture might therefore separate:
Speed
+
Geographic Relevance
+
Semantic Relevance
+
Data Quality
+
Freshness
The objective is not simply:
“Return something quickly.”
It is:
“Return useful things quickly.”
That distinction is central to the LeeX vision.
Where AI Enters the Architecture
AI can eventually contribute to query understanding, intent interpretation, classification and ranking.
But AI should not be responsible for searching one million raw records from scratch.
Instead:
User
↓
AI / Intent Layer
↓
Structured Query
↓
Location Index
↓
Candidate Generation
↓
Ranking
↓
AI-assisted Explanation
↓
Result
This architecture gives AI a focused role.
The database handles structured retrieval.
The geospatial layer handles geography.
The ranking system handles relevance.
AI can help interpret and connect those layers.
For Oscar Awowari, this is an important distinction in building an AI-ready city discovery ecosystem.
One Million Locations Is a Design Milestone
Reaching one million indexed locations would not simply be a storage milestone.
It would represent a much larger engineering challenge.
At that point, the system needs to answer difficult questions:
Can we find the right candidates quickly?
Can we maintain accurate location identities?
Can we keep information fresh?
Can we rank results effectively?
Can the infrastructure handle increasing traffic?
Can the system continue to provide useful discovery without becoming slow?
These are the questions that turn a location database into a discovery engine.
The LeeX Approach
For Oscar Awowari, Founder and CEO of LeeX, the larger objective is not to build the biggest database simply for the sake of having millions of records.
The objective is to build a system where city information becomes increasingly structured, searchable, connected and useful.
A million locations should therefore not mean a million things the system checks on every request.
It should mean a million locations that have been organized into an architecture capable of narrowing the problem intelligently.
The core pattern is simple:
1 Million Locations
↓
Indexes
↓
Candidate Generation
↓
Filtering
↓
Ranking
↓
Top Results
That is how a city discovery engine can grow without turning every search into a marathon.
Scale is not about making the system examine more data.
Good architecture makes it possible to examine less data—and still find the right answer.
Top comments (0)