Proximity Service
Proximity service design for indexing locations and querying nearby results.
A proximity service answers a deceptively simple question: what is near this point? Products like Yelp, ride-hailing apps, food delivery, and store locators all depend on it. The difficulty is not storing latitude and longitude. It is finding a small relevant set of nearby records quickly when the total dataset may contain millions of businesses spread unevenly across the map.
A clean design usually separates two concerns.
Business service owns the source of truth
The business service handles create, update, delete, and detail lookup for places such as restaurants or shops. It stores canonical business attributes: name, category, opening hours, address, and raw coordinates. This service is optimised for correctness and operational updates, not for radius search.
Location service is optimised for lookup
The location service maintains a search-friendly spatial index. A common approach is geohash, which converts latitude and longitude into a string whose prefix represents a region. Nearby points often share a prefix, so a lookup can start with a prefix match instead of scanning the entire table.
That is the point of the index. Without it, a database would need to compute distance from the query point to every business before filtering. That becomes expensive very quickly.
How a query works in practice
A user supplies a location and search radius. The location service first converts the point to one or more spatial cells. It queries candidate businesses from those cells, then applies an exact distance formula such as Haversine to remove false positives. This two-step approach is common: a coarse spatial filter reduces the candidate set, and an exact distance check produces correct results.
The service then ranks results. Distance matters, but it is rarely the only signal. Availability, business status, popularity, delivery radius, and paid ranking rules may also affect ordering.
Why geohash is useful and where it breaks down
Geohash is attractive because it is simple to generate, easy to index, and works well for prefix lookups. It also lets the system scale horizontally because nearby data tends to cluster by key prefix.
Its weakness is that geography is not evenly distributed. A dense city cell may contain thousands of businesses while a rural or ocean cell contains none. Edge cases also matter: two points that are physically close can fall on different cell boundaries, so the query must inspect neighbouring cells as well. A prefix match alone is not enough.
Write path and refresh strategy
When a business changes location or opens a new branch, the business service emits an update and the location index is refreshed. This can be synchronous for small systems, but larger platforms usually update the search index asynchronously through a queue or stream. That keeps writes resilient but introduces brief lag.
Operational concerns
Hotspots are common. City centres receive far more traffic than suburban areas. Popular queries are good candidates for caching, but caches must expire quickly if business status changes often. The system also needs guardrails for bad GPS data, spoofed client locations, and privacy rules around storing user coordinates.
A good proximity service is therefore a combination of spatial indexing, exact filtering, ranking logic, and operational discipline. The map pin is only the start. The real work is making neighbourhood search fast, relevant, and correct under load.