Designing a Geospatial Location Service

A geospatial service finds nearby restaurants, drivers, friends, or any entity within a geographic radius.

Requirements

• Find all restaurants within 5km of (lat, lng)
• Update driver locations every 5 seconds
• 100M location updates/day
• Response time <100ms

Geohashing

Divides Earth into a grid of cells, each with a string code.

Precision 1: 5000km × 5000km (1 char)
Precision 4: 40km × 20km (4 chars)
Precision 6: 1.2km × 0.6km (6 chars)
Precision 9: 4.8m × 4.8m (9 chars)

Locations with same prefix are geographically close.

San Francisco: 9q8yy...
Nearby location: 9q8yz...
Same prefix (9q8y) → nearby

Caveat: Edge case — locations near cell boundaries might have different prefixes despite being close. Solution: Check 9 surrounding cells.

Redis GEO

Redis uses geohash internally with sorted sets.

GEOADD restaurants -73.9857 40.7484 "restaurant:123"
GEOSEARCH restaurants FROMLONLAT -73.98 40.75 BYRADIUS 5 km ASC

H3 Hexagonal Indexing (Uber)

Divides Earth into hexagonal cells at different resolutions.

Advantages over squares:

• Equidistant neighbors
• Smooth grid transitions
• Better for routing, surge pricing

Quadtree

Recursively divides 2D space into quadrants.

Root: Whole Earth
├── NW quadrant
│   ├── NW sub-quadrant
│   └── ...

Good for: Points of interest with uneven geographic distribution.

Architecture

Location Updates → Kafka → Location Service
                               ↓
                         Redis GEO

Nearby Query → API → Redis GEOSEARCH → Results

Conclusion

Redis GEO (backed by geohash) is the easiest production solution. Use H3 for more complex spatial analytics and routing problems.