Ride-Sharing Dispatch, Actually Explained

A ride-sharing dispatch system's whole job is simple to say: match someone who wants a ride to someone nearby who can give them one, fast, and at a price that reflects supply and demand right now. That's the entire promise.

Everything below this point is about honoring that promise once both sides of the match — riders and drivers — are moving, arriving continuously, and numerous enough that a match that's locally correct for one rider can still be a globally worse outcome for the city. The query framing (“find the nearest driver”) is the wrong mental model from the start, and the rest of this guide is about why.

Before reaching for a geospatial index, it's worth being explicit about what this system is actually on the hook for — the same way you'd scope it out loud in an interview before drawing a single box.

That consistency split — loose for location, strict for reservation — is the single decision everything below inherits.

Numbers here are explicit back-of-envelope estimates, not measured production values — the point is to find the one number that actually constrains the design, not to be precise.

Before drilling into any one piece, here's the system end-to-end: a rider's request reaches the matching service, which searches a geospatial index kept fresh by a constant stream of driver location updates, and returns a matched driver. The API contract and data model below are what every later section refines — nothing past this point replaces this picture, it only explains why each piece of it exists.

The “Geospatial Index” box is a cluster, not one node. Driver locations are keyed by a geohash prefix — length 6 works out to roughly 1.2km × 0.6km cells, small enough for a useful “nearby” search — and each prefix is assigned to a shard by consistent hashing, so a lookup for one neighborhood only touches one or two shards. That's the piece that actually absorbs the ~250,000 writes/second from the capacity estimate; no single node has to.

Three different write patterns, three different stores. DriverLocation is overwritten every few seconds for a million drivers — the sharded in-memory geo index from above, TTL'd, no durability needed since a stale entry just gets overwritten next update. Ride is the opposite: infrequent, high-value state transitions that need ACID guarantees, so it lives in a relational store where every transition is kept as an immutable event — support and disputes need to reconstruct exactly what happened to a specific ride. Zone is small, changes rarely, and is cheap to cache in full on every matching-service instance.

The simulator solves its 4-rider batch exactly, by brute force, to make the point clearly. Real batches during a surge can have thousands of riders and drivers in one region, and the exact solution (the Hungarian algorithm, O(n³)) gets too slow to run inside a 2-3 second window at that size — production systems fall back to a faster approximate assignment (greedy on sorted distances, or a bounded local-search heuristic) that captures most of the benefit without the cubic cost.

The pattern mirrors the data model split: ephemeral, self-healing location data can tolerate loss because it's constantly being refreshed anyway; durable ride state cannot, and is engineered accordingly.

Driver-submitted location is a self-reported signal, which means it can be spoofed — a driver claiming to be in a high-surge zone they're not actually in is a real abuse pattern, worth cross-checking against plausible movement speed between consecutive updates. Location data is also sensitive personal information for both riders and drivers; access to raw location history should be scoped tightly, and retention of precise historical pings minimized once a ride is complete rather than kept indefinitely by default.