Design the Data Flow Behind a Food Delivery App's Restaurant List

Design the data flow behind the restaurant list in a food delivery app such as Uber Eats. When a customer opens the app with a delivery address, the home screen shows a list of restaurants that can deliver to that address. Design how restaurant data flows from the places where it changes into that list, and how the list is served to customers. Assume the list depends on data that changes at very different rates: - **Restaurant profile**: name, cuisine, location, images, delivery area and opening hours, which change rarely. - **Restaurant status**: open, closed or temporarily paused, which changes during the day. - **Operational signals** shown on each list item, such as the estimated delivery time, which change continuously. ```hint Separate by rate of change Some attributes change a few times a year and others every minute. Ask how that difference should shape where each attribute is stored and when it is combined into the list. ``` ```hint Location is the key Think about what you would precompute so that "restaurants that can deliver to this address right now" is a cheap lookup rather than a scan over all restaurants. ``` ### Clarifying Questions - Which fields does each list item show (name, rating, estimated delivery time, delivery fee, promotions), and which must be fresh within seconds? - Is ranking or personalization in scope, or only filtering by availability? - How is deliverability defined: a radius, a delivery area drawn per restaurant, or travel time? - How quickly must a restaurant that pauses orders disappear from the list? - What scale should the design assume: number of cities and restaurants, and peak list requests per second? ### What a Strong Answer Covers - Requirements with a freshness target for each kind of attribute - The write path: how restaurant and operational changes are captured and propagated - Geographic indexing of delivery areas, and how the candidate set for an address is computed - The read path: candidate retrieval, filtering, enrichment, ranking, pagination and caching - Consistency trade-offs, such as briefly stale "open" status, and their impact on customers - Scaling for meal-time peaks, failure handling and observability ### Follow-up Questions - A restaurant pauses orders during a rush. How quickly does it disappear from lists, and what happens to a customer who already sees it? - How would you add personalized ranking without breaking the latency budget? - How would you support search by cuisine or dish on top of the same data flow? - The geographic index becomes corrupted. How do you rebuild it without an outage?