Marketplace
Real-time Marketplace Dispatch & Matching
Match riders and drivers (or orders and couriers) in real time with geo-aware routing.
Scale to anchor on
Hundreds of millions of users, millions of active drivers globally, sub-second matching, billions of location updates per day.
Requirements
Functional
- Match a rider to the best nearby driver in seconds.
- Handle driver / rider cancellations.
- Support batching (Eats: multiple orders per courier).
- Respect business rules (eligibility, region, premium tiers).
Non-functional
- Low matching latency.
- Handles noisy / late / missing GPS.
- Survives city-level demand spikes.
High-level architecture
Drivers stream location updates into a geo-indexed store (H3 cells). On request, the dispatcher queries nearby drivers from the rider's cell, scores candidates with an objective function (ETA, cost, fairness), and reserves the chosen one with a short lease. State machines manage acceptance, cancellation, and re-dispatch.
Components
Location ingestion
Streams driver locations into a partitioned geo store.
Geo index (H3)
Cell-based lookup for 'drivers near point'.
Dispatcher
Scores candidates and reserves with a short lease.
Trip state machine
Manages lifecycle from request → match → en route → complete.
Eligibility service
Per-driver, per-region rules (vehicle, tier, suspensions).
Key decisions
H3 hexagonal indexing over lat/long grid.
Uniform neighbor distances and adjacency make geo queries clean and avoid grid-edge pathologies.
Optimistic lease on driver.
Avoids double-dispatch when two riders target the same driver simultaneously.
ETA and fairness in the scoring function, not pure distance.
Pure nearest-driver creates skew that drivers can game.
Tolerate late location updates.
GPS is unreliable; the dispatcher must reason about staleness and confidence.
Pitfalls
- Single-region dispatcher; latency spikes during regional incidents.
- Synchronous reads to all drivers in a city — collapses under load.
- Trusting GPS unconditionally.
- No rebalancing of driver supply — surge alone isn't sufficient.
Follow-up questions
- How do you handle 100k drivers reporting position once per second?
- How do you keep two riders from being matched to the same driver?
- How do you handle a city-wide demand spike?
- How does Eats batching change the dispatch problem?