System Design

Restaurant Menu

Design the restaurant menu service behind a food delivery app like DoorDash or Uber Eats.

Functional requirements

• Return a store's full menu: sections, items with name, description, price, and photo URL, plus modifier groups (e.g., size, toppings) with their own prices and selection rules.
• Let restaurant staff mark an item or a single modifier option sold out, and restore it later, so customers stop seeing it as orderable.
• Let restaurant staff change item prices and descriptions and add or remove items, with the change reflected in the customer app.
• Expose each store's hours so the app can show it as open, closed, or opening later today in the store's own local time.
• Return one item's detail (current price, modifier options, availability) when a customer taps it, so a cart can be priced correctly.

Non-functional requirements

• Menu reads are the critical path: p99 menu fetch latency under 150ms, since every app open and every store page load hits this service.
• Availability over consistency for menu content: a price or description edit may take up to 60 seconds to reach all customers, and a slightly stale description is acceptable.
• Sold-out state is the exception to that stance: an item marked sold out must stop being orderable within 5 seconds, because selling an unavailable item forces a canceled order.
• Menu data is durable: an acknowledged edit must survive the loss of a node, and losing a store's menu takes that store offline for ordering.
• A customer is never charged an old price: checkout revalidates price and availability against the store of record, so a stale client cannot order at a price the store has withdrawn.

Scaling & constraints

• 500,000 active stores, each with roughly 80 items across 8 sections and 15 modifier groups.
• 40,000 menu reads per second at the dinner peak against about 2 menu content edits per second across all stores, a read to content-edit ratio near 20,000:1, and near 130:1 once sold-out toggles are counted as writes.
• A rendered menu response is about 60 KB of JSON; the stored menu record without images is about 25 KB per store.
• Sold-out toggles are far more frequent than content edits: about 2 million a day, spread across roughly 300,000 stores, or 60% of the base, that toggle at least one item on a given day, peaking at 300 per second during the dinner rush.
• Traffic is heavily skewed: the top 5% of stores take about 60% of menu reads, and one promoted store can reach 500 menu reads per second within five minutes of a push notification.
• Menu versions are retained for 90 days for order disputes, and the store count grows about 30% per year.

Out of scope

• Cart, payment, and order dispatch; this service answers the revalidation read at checkout but does not own the checkout flow.
• Store search, ranking, and the customer home feed.
• Photo upload, image resizing, and image CDN delivery.
• Restaurant onboarding and bulk menu ingestion from POS vendors.