Proximity is a database problem, not an application problem

A tourism platform needs to answer what is near me across hotels, restaurants and attractions. It is the first thing a user does and the last thing that should be slow.

The version that does not work stores coordinates as strings, fetches candidates, and sorts by computed distance in application code. It is quick to write and works perfectly in testing, because testing has forty venues. It fails at exactly the moment the catalogue becomes valuable, and it fails by getting gradually slower rather than by breaking, which is worse.

The version that works stores GeoJSON points with spatial indexes and lets the database answer. The cost is discipline on the way in: coordinate order matters, and a spatial index will happily store a point in the sea.

The genuinely fiddly part is that three venue types are three collections with different shapes, and the user wants one ranked list. So the proximity endpoint runs the spatial queries independently and merges them into a single distance-ordered, filtered, paginated result. That controller is the largest business module in the project, and that is the right place for the complexity to live.