Geospatial: Nearby Drivers and Stores

In one line

Redis GEO stores longitude/latitude points in a sorted set, using a 52-bit geohash as the score, and answers "what's within 5 km of here?" with GEOSEARCH. It's fast and simple, and the hard parts at scale are update volume, hot regions and stale positions.

0/6 · 0%

Think of it like this

A city map divided into a grid of numbered squares, where nearby squares have nearby numbers. To find taxis near you, you look in your square and its neighbours, then measure exact distances only for the few taxis you found.

Key ideas

01
Commands: GEOADD key [NX|XX] [CH] lon lat member (longitude first!), GEOPOS, GEODIST key a b km, GEOHASH, GEOSEARCH key FROMLONLAT lon lat | FROMMEMBER m BYRADIUS r km | BYBOX w h km [ASC|DESC] [COUNT n [ANY]] [WITHDIST] [WITHCOORD], GEOSEARCHSTORE. GEORADIUS/GEORADIUSBYMEMBER are deprecated since 6.2.
02
Internals: a geo key is a sorted set. The score is a 52-bit interleaved geohash, so points close on the map usually have close scores. GEOSEARCH computes the 9 geohash cells covering the area, range-scans them in the sorted set (O(log N + M)), and filters by exact distance. You can use ZREM, ZCARD and ZSCAN on geo keys.
03
Accuracy: distances use the Haversine formula on a sphere, which can be off by up to ~0.5% at the extremes. Valid latitudes are ±85.05112878 degrees (the geohash projection's limit). That's fine for "nearby" features, not for surveying.
04
COUNT n ANY returns as soon as n matches are found (faster, not necessarily the nearest). Without ANY, Redis must collect all matches in the area and sort them, which can be slow in dense areas with a big radius.
05
Stale positions: a geo set has no per-member TTL. Pair it with a sorted set of last-update timestamps (or 7.4+ hash-field TTLs, or per-driver keys with TTL) and remove drivers who stopped reporting.

Code & diagrams

drivers.redisredis

127.0.0.1:6379> GEOADD drivers:blr 77.5946 12.9716 d:1 77.6101 12.9352 d:2 77.7500 12.9900 d:3
(integer) 3
127.0.0.1:6379> GEOSEARCH drivers:blr FROMLONLAT 77.5900 12.9700 BYRADIUS 5 km ASC COUNT 10 WITHDIST
1) 1) "d:1"
   2) "0.5286"
2) 1) "d:2"
   2) "4.3970"
127.0.0.1:6379> GEODIST drivers:blr d:1 d:3 km
"16.8411"
127.0.0.1:6379> TYPE drivers:blr
zset
127.0.0.1:6379> ZSCORE drivers:blr d:1                 # the geohash score
"3480345946284867"
# Driver moves: GEOADD again (XX = only update existing)
127.0.0.1:6379> GEOADD drivers:blr XX 77.5950 12.9720 d:1
(integer) 0
# Track freshness separately and prune stale drivers
127.0.0.1:6379> ZADD drivers:blr:seen 1727520000 d:1
127.0.0.1:6379> ZRANGE drivers:blr:seen -inf 1727519940 BYSCORE   # silent > 60 s
1) "d:3"

geo-sharding.mermaiddiagram

Rendering diagram…

Interview problem

The problem

Find the nearest drivers within 5 km

Design "find the nearest available drivers within 5 km" for a ride-hailing app. Discuss geo indexing, radius search, driver updates, hot regions, sharding by geography, and stale locations.

You're given

2M active drivers worldwide
Updates every 4 s per driver (~500K writes/sec)
10K ride requests/sec at peak
Only available drivers should match

The interviewer follows up

Why not store locations in PostgreSQL with PostGIS?

When it breaks

Swapping latitude and longitude in GEOADD

What you see

Points land in the wrong place (or ERR invalid longitude,latitude pair for latitudes beyond ±85); searches return nothing or nonsense.

Fix & prevent

Remember "longitude first" (x, then y); wrap geo calls in a small typed helper.

Drivers who went offline keep getting matched

What you see

Riders are assigned to ghosts, requests time out, and match rates fall.

Fix & prevent

Track last-seen timestamps and prune; remove drivers on logout or trip acceptance.

Explain it without notes

How can a sorted set answer a radius query?

Practice

Store 5 stores in your city and find the 2 nearest to your home with distance.

Trade-offs

↔
Redis GEO is fast and simple for point-in-radius queries; complex polygons and routing belong in PostGIS or a dedicated geo service.
↔
Smaller geographic shards spread load but require multi-cell queries near cell borders.

Done when you can

I can add, update and search points with the modern GEO commands.
I can design a nearby-drivers system with sharding and stale-location handling.

Command Palette