Finding nearby drivers sounds straightforward.
In practice, it quickly becomes one of the hottest paths in a ride-sharing platform.
Every ride request needs an answer within milliseconds while thousands of drivers continuously move throughout the city.
Running database geospatial queries for every request would make dispatch increasingly expensive as traffic grows.
Instead, driver locations were maintained in Redis.
The Problem
Ride requests happen continuously.
At the same time, drivers constantly update their locations while changing between online, offline, busy, and unavailable states.
The dispatch service needed to answer one question very quickly:
Which nearby drivers are currently eligible to receive this ride?
Location alone wasn't enough.
The system also needed to consider vehicle type, driver availability, and whether a driver was already participating in another ride or carpool.
Keeping Driver Locations in Memory
Whenever a driver came online, their latest coordinates were stored inside Redis.
As drivers moved, only their location needed to be updated.
This allowed nearby searches to execute entirely in memory rather than scanning the primary database.
Driver locations change every few seconds.
Rather than constantly updating the primary database, rapidly changing location data was stored in Redis while MongoDB remained the source of truth for long-lived business data.
Driver Discovery
When a passenger requested a ride, the dispatch service first searched Redis for nearby drivers within a configurable radius.
The result was only a candidate list.
Each candidate still needed to pass business validation before receiving the request.
This included checks such as:
- online status
- compatible vehicle type
- no active ride
- no active carpool
Only eligible drivers received the ride request.
Enriching Results Efficiently
Redis returned nearby driver identifiers.
The remaining operational data was retrieved in batches before applying eligibility checks.
Fetching driver state together avoided unnecessary network round trips while keeping dispatch latency predictable.
Finding nearby drivers is a geospatial problem.
Determining whether they should receive a ride request is a business problem.
Keeping these responsibilities separate made the dispatch pipeline easier to evolve without affecting the location search itself.
Lessons Learned
Fast geospatial search alone does not build a dispatch system.
Location discovery is only the first stage.
Filtering nearby drivers using operational state before dispatching requests keeps the system responsive while ensuring drivers only receive rides they can actually fulfill.