Overview
Dispatching a ride involves much more than finding the nearest driver.
The platform continuously tracks driver availability, discovers nearby eligible drivers, and broadcasts the ride request to them in real time. Interested drivers can submit their own offers, allowing the rider to compare multiple options before selecting one. Only after the rider accepts an offer is the ride assigned to a driver.
The goal was to keep dispatch fast without sacrificing consistency.
The Problem
A simple geospatial search isn't enough.
The dispatch system needed to consider:
- driver's current availability
- vehicle compatibility
- active ride state
- active carpool participation
- duplicate ride requests
- preventing duplicate offers
- ensuring only one offer can ultimately become the assigned ride
while maintaining a responsive experience for both riders and drivers.
Architecture
The dispatch pipeline separates discovering nearby drivers from determining whether they are actually eligible to receive the ride.
Only drivers that satisfy every business rule receive a real-time ride request.
Engineering Decisions
Finding nearby drivers and determining who should receive a ride request solve different problems.
Redis efficiently discovers nearby drivers, while application-level filtering determines whether each driver is currently available, supports the requested vehicle type, and isn't already participating in another ride or active carpool.
Rather than broadcasting ride requests, the platform maintains each online driver's connection state and delivers ride requests directly to nearby drivers, allowing them to submit offers without notifying drivers that are unable to fulfill the request.
This minimizes unnecessary network traffic while reducing dispatch latency.
Multiple drivers can submit offers for the same ride, but only one offer should ultimately become the assigned ride.
When the rider selects an offer, the platform performs the assignment atomically, rejects competing offers, and prevents any subsequent selections from modifying the ride.
Challenges
Real-time dispatch is constantly changing.
Drivers move every few seconds.
Connections disconnect unexpectedly.
Drivers transition between online, offline, active rides, and carpools throughout the day.
Because of this, dispatch cannot rely solely on database state.
Instead, rapidly changing operational data is maintained in Redis while MongoDB remains the system of record for persistent ride information.
This separation keeps dispatch responsive without compromising consistency.
Outcome
The resulting dispatch system discovers nearby drivers in real time, filters them using business rules, and allows eligible drivers to compete by submitting offers. Riders can compare available options before making a decision, while the platform guarantees that only one offer can ultimately become the assigned ride. This provides marketplace-style flexibility without compromising consistency.
Related Engineering Notes
Building Geospatial Driver Discovery with Redis
How Redis geospatial indexing enabled fast nearby driver discovery without relying on expensive database geospatial queries.
Preventing Multiple Drivers from Winning the Same Ride
Marketplace-style ride requests introduce a different concurrency problem. This article explores how ride assignment was designed to guarantee that only one driver's offer can ever become the final booking.