Consider a ride-sharing app like Uber. A user opens the app looking for the nearest available driver. There are 100,000 active drivers in the city. How do you find the 10 closest ones in under 100 milliseconds?

The naive approach is straightforward: calculate the distance from the user to every single driver and return the closest 10. With 100,000 drivers, that means 100,000 distance calculations per request. At 1,000 requests per second, the system performs 100 million calculations per second. This does not scale.

Adding a database index does not solve this. Traditional B-tree indexes work on one dimension at a time. They can efficiently answer "find all users with age > 25" but struggle with "find all drivers within 2km" because location has two dimensions that must be queried together.

This is the core challenge of location data. It shows up in ride-sharing, food delivery, dating apps, and real estate search, where nearby queries need a different access pattern from ordinary single-column lookups.

A strong interview answer uses a two-step shape: generate a small set of nearby candidates, then rank those candidates with exact distance, ETA, availability, or business rules.

These techniques appear in many system design interviews:

In an interview, keep the shape simple: