System architecture for an Uber-like ride-hailing platform

Design the system behind Uber's ride-hailing service. Lay out the main components, show how they work together, and explain how the design holds up at scale. Assume the standard core scope unless the interviewer narrows it: a rider requests a ride, the system finds and assigns a nearby driver, both follow the trip in real time, and the rider pays at the end. ```hint Size the location stream first Estimate how many driver location updates arrive every second and what a nearby-driver search has to read, then let those two numbers shape the design. ``` ### Clarifying Questions - Which products are in scope: standard rides only, or also shared rides, scheduled rides and food delivery? - Should pricing, surge and payments be designed in detail, or treated as services I call? - Are we designing for one city first or a global footprint across many cities? - How deep should I go: components and their trade-offs, or down to data models and storage? ### What a Strong Answer Covers - Scoped requirements with rough estimates of trips, online drivers and location update rates - How driver locations are ingested, stored and searched by proximity, and how fresh that data must be - The matching flow and trip lifecycle, including what stops two riders from getting the same driver - Data store and partitioning choices for different kinds of data - Failure handling for dropped connections and service crashes, and the metrics that show the system is healthy ### Follow-up Questions - Driver locations change constantly. How stale can a stored location be before matching suffers, and how do you keep it fresh? - What happens if the rider's phone loses connection mid-trip, or the matching service crashes right after a driver accepts? - A stadium empties and thousands of people request rides in one small area at once. What strains first, and how does your design cope?