Design the backend that pairs riders with nearby drivers and shepherds each trip from request to completion (think a popular ride-hailing app operating in dense metros). Drivers stream their GPS position continuously; riders open the app, request a ride, and expect a matched driver within seconds with a live position feed the whole way.

Operating context. One large metro region at launch, ~200k drivers online at evening peak, ~50k concurrent riders. Drivers emit a location ping every 4 seconds (≈50k pings/sec sustained, 2–3× that at rush hour). Ride requests peak around 3k/sec. Demand is spiky and geographically skewed: a stadium letting out or a rainstorm creates a hot cell where requests spike 10× while supply stays flat. Matching should feel instant — a rider should get a driver assignment in p99 < 5 s — and the map should update smoothly.

Out of scope. Payments and fare settlement, the routing/ETA engine internals (assume a maps service you call), fraud and identity, driver onboarding, ratings and support tooling. Assume separate teams own those; you may call them as black boxes.

What to produce. A high-level architecture covering: how driver location pings are ingested and indexed for fast geospatial nearest-driver queries; the matching flow that reserves a driver for a request without double-assigning; the trip state machine and where it is authoritative; how surge pricing plugs into matching without stalling the hot path; how riders and drivers receive real-time updates (position, assignment, status); and how dispatch stays fair when a hot cell has far more demand than supply. Sketch the components and the request/event flow between them; we will probe specifics at checkpoints.