Design a Shared Autonomous Vehicle (Robotaxi) System

Problem Statement: Robotaxi Fleet

A robotaxi system dispatches a fleet of self-driving vehicles to riders with no human driver in the loop. The product looks like Uber, but the engineering problem is inverted: there is no driver to absorb the messy edge — a confused pickup spot, a double-parked truck blocking the lane, a passenger who left a bag on the seat. The platform itself must handle everything the driver used to.

Three responsibilities define the system. First, dispatch: match a rider to the nearest available vehicle that is actually allowed to make the trip. Second, autonomy operations: every vehicle streams high-rate telemetry — pose, speed, battery, sensor health, perception confidence — and when it gets stuck it escalates to a remote-assist operator who gives high-level guidance (it is safe to proceed, take this detour) without driving frame-by-frame. Third, the Operational Design Domain (ODD) — the geofenced set of roads, weather, and times the vehicles are certified to drive — which means a trip that would leave the ODD must never be offered in the first place.

The scale that matters here is not rides per second. A city fleet is hundreds to a few thousand vehicles, so booking QPS is modest. What is large is telemetry throughput and safety latency: roughly 2,000 vehicles each emitting 20 messages per second is ~40,000 messages/second of safety-relevant state, and a remote-assist escalation must reach a human in under one second. Get dispatch wrong and a rider waits a few extra minutes; get the safety path wrong and someone is hurt. That asymmetry is why this design is built around the safety pipeline first and the marketplace second.