Overview
Executive summary
The chain operated 40+ quick-service outlets across three regions with different POS vendors, spreadsheet inventory, and aggregator tablets that did not talk to the kitchen. Peak-hour errors, slow close-outs, and blind spots on food cost made franchise reviews painful.
We delivered an end-to-end restaurant management system: unified ordering from dine-in and delivery apps, station-aware KDS, recipe-level inventory, and HQ analytics — rolled out in waves with offline-safe registers and a single menu master.
Challenge
Business problems and how we solved them
1Different POS at every outlet
Menus, pricing, and reports varied by store — HQ could not compare apples to apples.
Technique · Multi-tenant SaaS + centralized menu versioning.
Solution · One menu and tax engine promoted from HQ; outlet overrides only where legally required; nightly sync to all registers.
2Aggregator orders re-keyed into kitchen
Swiggy and Zomato tablets sat beside the grill — missed items and duplicate tickets at peak.
Technique · Aggregator middleware → same order bus as POS.
Solution · Webhook ingest normalizes external orders into internal tickets; KDS sees one queue with channel badges; 99.2% acceptance without manual entry.
3Inventory disconnected from sales
Stockouts on bestsellers weekly; end-of-month food cost surprises.
Technique · Recipe BOM + PAR alerts + purchase order workflow.
Solution · Each sold SKU deducts ingredients; low-stock alerts by daypart; managers approve POs from tablet with vendor catalog.
4Kitchen bottlenecks invisible to managers
Expo shouted tickets; no data on station load or bump times.
Technique · KDS routing rules + bump analytics.
Solution · Items route to grill/fry/cold by SKU; bump timestamps feed throughput dashboards; +17% tickets per peak hour after rebalancing stations.
System design
Architecture diagrams
Order flow across channels, in-store operations hub, multi-location hierarchy, and platform services.
Channels → POS → KDS → inventory deduct → HQ analytics.
POS, aggregators, KDS, and inventory on a shared order bus.
Franchise HQ, regions, and 40+ outlets on one tenant.
POS/KDS clients, API, PostgreSQL, Kafka, Redis, and reporting.
Engineering
Platform build and rollout
Multi-tenant core
Single schema with tenant_id per franchise; menu, pricing, and tax rules versioned and promoted from HQ.
- outlets
- menus
- orders
- recipes
- staff
Real-time order bus
Kafka topics per region; Redis holds open tickets for sub-second KDS updates when LAN is healthy.
Topic partition
By outlet
Redis TTL
Open shift
Retry policy
Exponential
DLQ
Aggregator fails
Offline-first POS
IndexedDB queue on register; sync on reconnect with server-wins conflict for payments, client-wins for open items.
- lan_blip
- isp_outage
- end_of_shift_sync
Rollout
Wave deploy: 5 pilot stores → 15 → remainder; parallel menu cutover weekends with rollback tablets kept on legacy.
- 5 stores
- 15 stores
- 40+ stores
