Design CanvasOpen the canvas

Design a Meal Delivery Service

Customers find restaurants near them, order food, pay, and watch a courier approach on a map. Couriers report their position constantly, and each restaurant gets the order on a tablet. Dinner time is several times busier than the afternoon, and a dish that is nearly sold out must not be sold to two people.

Constraints

  • Finding restaurants and placing an order must each respond within 400 ms; the payment processor alone takes about a quarter of a second
  • About 6,000 requests per second at peak, and three times that at dinner
  • Placing an order twice by accident (a double tap) creates one order
  • A dish with one portion left is sold to one person
  • Customers are charged through an external payment processor, and restaurants are told through an external messaging provider
  • Live courier tracking is nice to have, but ordering must work without it
  • Keep infrastructure under $14,000 a month
  • About 3 million dishes from 100,000 restaurants, and 150 million orders from 20 million customers

Scenarios to survive

Typical peak

Steady browsing with the usual rate of orders.

Interviewer asks: Browsing near me, ordering, and courier tracking behave very differently. Which of them share a service and which should not?

Dinner rush (3x)

Everything triples at dinner time.

Interviewer asks: Which part feels the dinner rush first, and which parts can wait a few seconds?

Courier tracking hangs

Whatever runs courier tracking becomes 15x slower.

Interviewer asks: Tracking hangs. Should an order wait for it, and what happens to the map the customer sees?

Restaurant messaging outage

The external messaging provider stops answering.

Interviewer asks: Restaurants cannot be told about orders. Do you still accept orders, and how do restaurants find out?

What a good design must do

  • Browsing and ordering meet the latency target at peak
  • The dinner rush passes
  • Total monthly cost stays within $14,000
  • Restaurants and couriers are in a geographic index
  • Something places orders, once, and never oversells a dish
  • A hung courier tracker does not slow ordering
  • Ordering keeps working when restaurant messaging is down
  • The design explains how the last portion of a dish is protected
  • Every query is answered through a key or an index, never by reading a whole table