Practice/Google/Design a fast food restaurant chain management system
Design a fast food restaurant chain management system
System DesignMust
Problem Statement
A global fast food restaurant chain operates thousands of locations across different regions, each serving its own menu with location-specific items and pricing. The company needs a centralized platform that manages these menus and delivers them to in-store digital display panels in real time. Each location may offer different items depending on the time of day — breakfast menus transition to lunch menus on a fixed schedule, and seasonal or promotional items rotate in and out based on directives from regional managers.
The digital panels inside each restaurant render rich media content — high-resolution images, animations, and video loops — that must load quickly and look consistent across all screens in a given location. These panels operate in environments where network connectivity can be unreliable, so the system must support offline-first behavior: panels should continue displaying the most recently synced menu even when connectivity drops and gracefully catch up when the connection is restored.
Beyond static menu display, the chain wants context-aware promotions that respond to real-world signals like local weather conditions, time of day, and current store occupancy. For example, panels might highlight hot beverages during cold snaps or push combo deals during peak lunch hours. Menu changes must be rolled out in stages — piloting at a small set of locations before expanding chain-wide — to minimize risk from pricing errors or poorly received items.
Key Requirements
Functional
- Location-specific menu management -- Regional managers configure menus, pricing, and item availability per location or location group, with time-based scheduling for daypart transitions like breakfast to lunch
- Rich media delivery to panels -- Serve high-resolution images, animations, and video content to in-store digital panels with fast load times and efficient bandwidth usage across thousands of locations
- Context-aware promotions -- Display dynamic promotions on panels based on contextual signals including local weather, time of day, and real-time store occupancy data
- Staged rollout with versioning -- Support gradual rollout of menu changes across location tiers with instant rollback capability if issues are detected at any stage
Non-Functional
- Scalability -- Support tens of thousands of restaurant locations, each with multiple display panels, receiving concurrent menu and media updates
- Latency -- Menu configuration changes propagate to connected panels within 30 seconds; media assets load on panels in under 2 seconds from local cache or CDN edge
- Availability -- Panels continue displaying the most recent valid menu during network outages lasting several hours, using local storage and offline-first architecture
- Consistency -- All panels within a single location display the same menu version simultaneously to prevent customer confusion at the counter
What Interviewers Focus On
Based on real interview experiences, these are the areas interviewers probe most deeply:
1. Offline-First Panel Architecture
Interviewers want to see how you keep panels functional when connectivity drops. They look for a clear local storage strategy, sync protocols, and conflict resolution when the panel reconnects.
Hints to consider:
- Think about what data the panel stores locally and how you version it so the agent detects stale content on reconnect
- Consider combining a pull-based heartbeat with push-based invalidation so panels know exactly when to fetch updates
- Plan for partial sync failures — what happens if only half the media assets download before the connection drops again
- Decide how you handle clock drift on panels for time-based daypart transitions without relying on a live server connection
2. CDN and Media Pipeline
Rich media must reach panels quickly and cost-efficiently across thousands of geographically distributed locations. Interviewers probe your understanding of asset pipelines, cache invalidation, and bandwidth optimization.
Hints to consider:
- Consider pre-positioning assets at CDN edge nodes close to restaurant clusters before a scheduled menu change goes live
- Think about generating multiple image resolutions and video bitrates to match different panel hardware capabilities
- Plan a cache warming strategy that downloads upcoming menu assets during off-peak hours to avoid bandwidth spikes during daypart transitions
- Address how you invalidate stale assets — content-addressable naming by hash versus explicit purge commands — and the trade-offs of each
3. Context-Aware Promotion Engine
Dynamic promotions based on external signals add real-time decision-making complexity. Interviewers explore how you ingest, process, and act on context data with low latency.
Hints to consider:
- Think about how you ingest weather data and occupancy signals — polling external APIs on a schedule versus receiving webhook-style events
- Consider a lightweight rules engine that evaluates promotion eligibility based on multiple context dimensions simultaneously
- Plan for fallback behavior when a context signal is unavailable — panels should still display a sensible default promotion rather than blank space
- Decide where the promotion logic executes — on the panel locally, on a regional edge server, or centrally — and justify your choice
4. Staged Rollout and Versioning
Safe deployment of menu changes across a chain with thousands of locations is operationally critical. Interviewers look for your rollback strategy and how you monitor rollout health.
Hints to consider:
- Think about grouping locations into rollout tiers — pilot stores, regional expansion, then full chain — with automated health-check gates between tiers
- Consider how you detect a bad rollout: panel error rates, manager-reported issues, or anomalous sales patterns at pilot locations
- Plan your data model so each menu version is immutable and rollback simply re-points a location to a previous version identifier
- Address what happens to in-flight customer orders when a menu version changes mid-service period