Katkat

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

UberSoftware Engineer · Onsite

Last updated

A system design interview question asking you to design the data flow behind a food delivery app's restaurant list for a customer's delivery address. It tests geographic indexing of delivery areas, propagating restaurant status and delivery-time changes, read-path latency, caching, and freshness trade-offs.

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.

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?

Hints

Hint 1

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 2

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.

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?