Global Restaurant Chain Menu Update System

0Problem RestatementProblem

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.

1Deep Dive — One menu, forty thousand restaurantsDeep dive

The same burger has a different price in Germany, a different name in Quebec, an allergen line required in the EU, and is sold out at one branch right now.

%%{init: {"look":"handDrawn","handDrawnSeed":7,"theme":"base","fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","themeVariables":{"fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","fontSize":"16px","primaryColor":"#fff4e6","primaryBorderColor":"#1e1e1e","primaryTextColor":"#1e1e1e","secondaryColor":"#e7f5ff","tertiaryColor":"#ebfbee","lineColor":"#1e1e1e","textColor":"#1e1e1e","mainBkg":"#fff4e6","nodeBorder":"#1e1e1e","clusterBkg":"#f8f9fa","edgeLabelBackground":"#ffffff","classText":"#1e1e1e"}}}%%
flowchart LR
  GLOBAL["Marketing renames an item globally"] --> WRITE["Update 40,000 menus"]
  WRITE --> PART["Some succeed, some fail"]
  PART --> DRIFT["Menus permanently inconsistent"]
  WRITE --> SLOW["Any global change is a migration"]
  DUP["The same description stored 40,000 times"] --> COST["Storage and review cost"]

%%{init: {"look":"handDrawn","handDrawnSeed":7,"theme":"base","fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","themeVariables":{"fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","fontSize":"16px","primaryColor":"#fff4e6","primaryBorderColor":"#1e1e1e","primaryTextColor":"#1e1e1e","secondaryColor":"#e7f5ff","tertiaryColor":"#ebfbee","lineColor":"#1e1e1e","textColor":"#1e1e1e","mainBkg":"#fff4e6","nodeBorder":"#1e1e1e","clusterBkg":"#f8f9fa","edgeLabelBackground":"#ffffff","classText":"#1e1e1e"}}}%%
flowchart LR
  BASE["Global base - items, descriptions, images"] --> CTRY["Country - prices, taxes, language, allergens, legal"]
  CTRY --> REG["Region / franchise - local items, promos"]
  REG --> RST["Restaurant - sold out, permitted price tweaks"]
  RST --> DAY["Daypart - breakfast / lunch / dinner"]
  DAY --> EFF["Effective menu - resolved per restaurant, per daypart"]
  EFF --> CACHE["Cached and pushed to apps and tills"]

2ArchitectureArchitecture

%%{init: {"look":"handDrawn","handDrawnSeed":7,"theme":"base","fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","themeVariables":{"fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","fontSize":"16px","primaryColor":"#fff4e6","primaryBorderColor":"#1e1e1e","primaryTextColor":"#1e1e1e","secondaryColor":"#e7f5ff","tertiaryColor":"#ebfbee","lineColor":"#1e1e1e","textColor":"#1e1e1e","mainBkg":"#fff4e6","nodeBorder":"#1e1e1e","clusterBkg":"#f8f9fa","edgeLabelBackground":"#ffffff","classText":"#1e1e1e"}}}%%
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.

3Scheduling 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.

4Safety

• 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.

5Wrap-UpWrap-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.