System design for the Uber Eats delivery platform: geo search, dispatch and live tracking

Design Uber Eats: the system that lets customers order food from nearby restaurants and have a courier deliver it. Treat this as a system design discussion. Lay out the architecture end to end, then go deeper on the parts the interviewer picks. ```hint Breadth first Get the whole life of one order on the board, from browsing to delivery, before drilling into any single component. Then look for the pieces that depend on answering "what is near this point" quickly. ``` ### Clarifying Questions - Is the scope all three sides (customers ordering, restaurants accepting and preparing, couriers picking up and delivering), or only the customer side? - What scale should I design for: a single city at launch, or a global service at the dinner peak? - Can payments be treated as an external provider, or is the payment flow itself part of the design? - Is grocery and convenience delivery in scope, or only restaurant meals? ### What a Strong Answer Covers - Clear functional and non-functional requirements, with rough capacity estimates - A complete end-to-end architecture before any deep dive: discovery, ordering, dispatch and live tracking - How locations are indexed for nearby restaurant search and for courier matching - The data model and partitioning choices, with the consistency that orders and payments need - Failure handling, scaling for meal-time peaks, and the metrics that show the system is working ### Follow-up Questions - Would you partition customer data by customer ID or by location? What does each choice cost? - Restaurants upload menu photos. How would you screen them for inappropriate content, and how would you balance precision against recall? - How does dispatch cope when couriers are scarce during a dinner rush?