Design a System for a Vehicle Fleet Collecting Map Data for Autonomous Driving

Design the system that runs a fleet of sensor-equipped vehicles whose job is to collect the data used to build and refresh maps for autonomous driving. The vehicles drive public roads while recording sensor logs, such as camera, lidar and GPS/IMU data. The system must decide where data is needed, get the recorded data off the vehicles, and make it available, organized and quality-checked, to the pipelines that build maps. Only the prompt was reported, so confirm the scope through the clarifying questions, and do not assume specific numbers until the interviewer gives them. Expect detailed questions about the collection workflow itself, not only about generic web-scale components. ```hint Follow the bytes Raw sensor logs are very large compared with ordinary application data. Work out how the data physically leaves a vehicle, and what that implies for latency, cost, and what must be checked before the data leaves the vehicle. ``` ```hint Coverage drives the work The fleet exists to cover roads whose map data is missing or stale. Think about how the system knows which road segments need data, and how it turns that into assignments for vehicles. ``` ### Clarifying Questions - How many vehicles and regions are there, how many hours does a vehicle drive per day, and how much data does it record per hour? - Is data offloaded at a depot (physical drives or a fast local link), uploaded over cellular, or both? - Is the system responsible for planning routes and assigning them to drivers, or only for ingesting what the vehicles collect? - How fresh must the map be: how soon after a road changes must new data reach map building? - Is map building itself in scope, or does this system end at delivering validated data to it? - What privacy requirements apply, such as blurring faces and license plates or deleting data on request? ### What a Strong Answer Covers - Clarified scope across mission planning, on-vehicle recording, offload and ingestion, processing, and the hand-off to map building - A back-of-envelope estimate of data per vehicle and per day that justifies the offload path - A data model for road segments, coverage, missions, drives and their recorded logs - Coverage and freshness tracking that turns stale or missing roads into collection missions - Reliable, resumable, verified ingestion with no silent data loss - Quality checks (sensor health, calibration, localization) with feedback to the fleet - Failure handling, privacy, retention and observability ### Follow-up Questions - A sensor on one vehicle was miscalibrated for a week before anyone noticed. How do you detect it, and which data do you quarantine? - Construction changes several roads in a city. How does that become new collection work, and how quickly? - How would you reduce the amount of data uploaded, for example by detecting changes against the current map on the vehicle? - Data must be deleted for privacy reasons after it has already been processed. How do you find and remove everything derived from it?