Global Restaurant Chain Menu Update System

0) Problem Restatement

Google asked: design a menu update system for a global restaurant chain (think tens of thousands of restaurants in many countries). Each restaurant has several menu-display devices: digital menu boards, self-order kiosks, POS terminals and tablets. Headquarters and regional managers publish menu and price changes, some scheduled (breakfast menu until 10:30, a new promo on Monday). Every device must show the correct, consistent menu, even if a restaurant's internet is flaky.

1) Menu Model: Layers with Overrides

• Global base menu: items, descriptions, images.
• Country layer: prices, taxes, language, legal info (allergens, calories), items added or removed.
• Region / franchise layer: local items, promos.
• Restaurant layer: sold-out items, local price tweaks (if allowed).
• Dayparts: breakfast, lunch and dinner schedules.

The effective menu for a restaurant = base + country + region + restaurant overrides, resolved for each daypart.

2) Architecture

flowchart LR
    ADM["HQ / regional editors"] --> MS["Menu Service - validate, version, schedule"]
    MS --> DB[("Menu layers + versions")]
    MS --> BLD["Build effective menus per store"]
    BLD --> CDN[("CDN - versioned menu bundles + images")]
    MS -->|"notify: new version"| PUSH["Push / MQTT to stores"]
    PUSH --> SG["Store gateway (edge box)"]
    SG -->|"pull bundle"| CDN
    SG --> D1["Menu boards"]
    SG --> D2["Kiosks"]
    SG --> D3["POS"]

• Versioned bundles: after a change is published, build the effective menu per store (or per group of identical stores) as an immutable bundle (JSON + image references) with a version number, and upload it to a CDN.
• Notify + pull: send a small "version 812 available, effective at 06:00" message to each store. The store pulls the bundle from the CDN. Periodic polling catches missed notifications.
• Store gateway (a small edge box in each restaurant): caches the bundle locally and serves all devices in the store, so they update together and keep working offline.

3) Scheduling and Consistency

• Bundles include future versions with effective times, delivered in advance. At 10:30 local time, every device switches to the lunch menu from its local copy, with no network needed at that moment.
• The gateway tells devices to switch atomically at the effective time, so the board and the kiosk never show different prices.
• POS pricing is the source of truth for charging, so the POS and displays use the same bundle version, and the version is included on receipts and orders for auditing.

4) Safety

• Validation before publish: every item has a price in each country, images exist, required legal fields are present, and the tax setup is valid.
• Staged rollout: pilot stores first, then a region, then global. Monitor device errors and order failures.
• Rollback: re-point stores to the previous version (they still have it cached).
• Offline stores: keep serving the last valid bundle, and alert HQ if a store is more than N versions behind.

5) Wrap-Up

Model menus as layers (global → country → region → restaurant) with dayparts, and build an immutable, versioned effective-menu bundle per store (or store group) served from a CDN. Notify stores of new versions and let an in-store gateway pull, cache and hand bundles to all devices, applying scheduled changes locally and atomically at their effective time. Validate, stage and roll back releases safely, and keep offline stores running on the last good version.