Build the matching/dispatch core of a ride-hailing marketplace at Uber/Lyft scale. Drivers stream their GPS over a persistent socket; riders tap "request" and expect a driver's phone to ring within ~3 seconds. The system must pick a driver who is geographically close, currently available, likely to accept, and quote a fare with a surge multiplier that's both real-time and stable enough not to flicker between offer and confirm. Out of scope for this canonical: payments, in-trip telemetry, fraud, accounting — this is the matching main flow only. The interesting pressure is: (a) the geo-index is **write-dominant** at ~125:1 vs reads — every driver heartbeat is a write, only one rider request consumes ~19 cells of fan-out — flipping every assumption the typical "read-through cache" canonical relies on; (b) demand is **violently skewed** — a single H3 r9 cell at MSG when a concert lets out can take 100x normal load while everything else is idle; (c) the dispatch path must be **sharded by geography**, not by tenant, because that's the only way one CPU can hold authoritative in-memory state for a contiguous patch of map.