How to Build a Production-Scale Platform with Full Stack + AI & IoT?
Discover how we built a production-scale Full Stack AI & IoT platform that grew from 20 to 400+ locations using cloud architecture, RabbitMQ, edge computing, AI automation, and scalable backend engineering to deliver reliable, high-performance enterprise applications.
Introduction
Most conversations about restaurant technology stop at the mobile app. Someone opens a menu, taps a few items, pays, and the order “just happens.” What’s rarely discussed is what happens in the seconds after that tap — the part of the system that never shows up on a screen but decides whether the kitchen gets the right ticket, on the right printer, at the right table, every single time, across hundreds of locations at once.
That’s the engineering problem this article is about.
Over the past few years, our team at Krishworks Technology Innovations has been building and operating the backend, cloud infrastructure, and IoT layer for a restaurant ordering and management platform. What started as a system supporting around 20 restaurant locations has grown into a platform now running in 400+ restaurants, processing a continuous stream of orders, printer jobs, menu updates, and analytics events every hour of every day.
This isn’t a marketing story about “digital transformation.” It’s a technical account of the architectural decisions — some of them made under production pressure — that let the system keep working as the number of restaurants, devices, and daily orders grew by more than an order of magnitude.
Beyond Food Ordering Apps
A food ordering interface is the visible 10% of a restaurant platform. The other 90% is infrastructure: a backend that validates and stores orders, a message broker that decouples the cloud from restaurant hardware, edge devices that talk to thermal printers over a local network, a caching layer that keeps cloud costs under control, an AI pipeline that turns a photographed menu into structured data, and a deployment system that can push software to hundreds of physically distributed devices without anyone visiting a restaurant.
None of that is optional once you’re past a handful of pilot locations. It’s the difference between a demo and a platform that a restaurant group can depend on for its daily revenue.
Why Modern Restaurants Need Intelligent Platforms
Restaurant operators don’t need “an app.” They need order accuracy, kitchen efficiency, uptime during dinner rush, and a way to onboard new locations in days rather than weeks. As a restaurant group grows from a handful of outlets to a regional or national chain, the requirements shift from “does it work” to “does it keep working when 400 things are happening in parallel, in 400 different physical locations, on hardware nobody is standing next to.”
That shift — from single-location software to distributed, fault-tolerant infrastructure — is the actual engineering story here, and it’s the same shift that shows up in industrial IoT, logistics, and manufacturing environments, not just restaurants.
The Story Behind This Engineering Journey
This article is written up from an internal engineering talk our team delivered, walking through the real system: the load balancer in front of the API, the RabbitMQ queues that connect the cloud to each restaurant, the Raspberry Pi devices sitting quietly in kitchens, and the caching layer we built after discovering our Firestore bill was driven by nearly 12 million reads a day. Where useful, we’ve also drawn on Hopa-Print, a related printer-orchestration system we engineered for a multi-location restaurant client, which is documented publicly as one of our case studies and referenced throughout this piece for its RabbitMQ-to-Raspberry Pi-to-thermal-printer design.
We’re publishing the architecture in detail — not a simplified diagram, but the actual reasoning behind each decision — because we believe the best way to demonstrate engineering capability is to show the work, including the parts that didn’t go smoothly on the first attempt.
The Challenge
Why Traditional Restaurant Software Doesn't Scale
A single-restaurant ordering system is a comparatively simple engineering problem: one location, one printer, one menu, predictable traffic. Most restaurant software starts life this way, and most of it breaks the same way when a business tries to grow past a handful of locations.
The failure pattern is consistent. The system was built assuming a direct connection between the backend and a single point of sale or printer. Menu management assumed one person updating one menu. Authentication assumed a flat list of users rather than a hierarchy of restaurant admins and a platform-level super admin. None of this is a coding mistake — it’s an architecture that matched the original scope and stopped matching the business the moment the business grew.
Operational Challenges
Multi-Location Management. Once a restaurant group operates more than a few locations, someone needs a single place to onboard a new restaurant, configure its menu and printers, and monitor whether its hardware is online — without touching code or infrastructure per location.
Hardware Integration. Every restaurant has its own printers, its own local network, and its own physical layout of kitchen stations. Software that assumes uniform hardware across locations runs into trouble the first time it meets a restaurant with a nonstandard printer model or an unreliable Wi-Fi router.
Cloud Challenges. As order volume grows, a backend built around synchronous request-response calls to every downstream system (including hardware) becomes a bottleneck and a single point of failure. A slow printer, a flaky local network, or a temporary outage at one restaurant should never be able to slow down or crash the ordering experience for every other restaurant on the platform.
Device Management. With a handful of devices, you can SSH into each one manually to apply an update. With hundreds of devices spread across independent physical locations — many behind consumer-grade routers, with no static IP and no on-site technician — manual device management stops being possible. You need remote visibility into device health and a deployment mechanism that doesn’t require anyone to be physically present.
Key Takeaway: The problems that show up at 400 restaurants aren’t more of the same problems you had at 20 restaurants — they’re different problems entirely. Synchronous designs, direct hardware connections, and manual device operations all work fine at small scale and become the primary source of outages at production scale.
From 20 Restaurants to 400+ Locations
Business Growth
The platform started as a fairly conventional food-ordering and restaurant-management system supporting around 20 locations. As the client’s restaurant network expanded, location count grew past 100, then 200, and eventually beyond 400 — with each new restaurant bringing its own menu, its own printer setup, its own local network conditions, and its own order volume pattern.
Engineering Challenges
Growth of this kind rarely announces itself gracefully. It shows up as a spike in Firestore billing, a support ticket about an order that printed twice, or a Raspberry Pi that silently stopped receiving updates because a firmware rollout script assumed sequential deployment across a device count that no longer fit inside the maintenance window. Each of these was a real production event that forced an architectural response rather than a quick patch.
Scaling Problems
Three scaling problems recurred throughout this project, and each maps directly to a section later in this article:
Database read costs growing faster than revenue — solved with a caching aggregation layer (see Intelligent Caching Strategy).
Hardware communication becoming a reliability bottleneck — solved by moving from direct connections to asynchronous, queue-based communication with edge devices (see Distributed Systems Using RabbitMQ and IoT Edge Computing with Raspberry Pi).
Manual onboarding and manual device operations becoming a labor bottleneck — solved with AI-assisted menu processing and a secure OTA update pipeline (see AI Development in Restaurant Automation and Secure OTA Update Pipeline).
Infrastructure Evolution
The infrastructure evolved from a single backend service talking directly to a handful of pilot locations, into a horizontally scaled, load-balanced backend that publishes events to RabbitMQ, with every restaurant’s Raspberry Pi subscribing only to the messages relevant to it. That single change — replacing direct hardware calls with an event-driven message queue — is arguably the one architectural decision that made 400+ locations possible without a corresponding 20x increase in engineering headcount.
Understanding the Complete Restaurant Ecosystem
Before going deeper into any single component, it helps to see the platform as three cooperating user roles sitting on top of one shared cloud infrastructure.
Customer Journey
A customer opens the ordering interface — built with Next.js, TypeScript, Redux Toolkit, and TanStack Query — browses the menu, adds items, and places an order. From their perspective, the interaction ends the moment the confirmation screen appears. Everything described in the rest of this article happens in the seconds after that screen loads.
Restaurant Admin
Each restaurant has an operator-facing dashboard for managing menus, viewing incoming orders, configuring kitchen printers, and pulling reports. This is where day-to-day restaurant operations happen: adding a seasonal item, marking a dish unavailable, or checking which printer handled a disputed order.
Super Admin
A platform-level administrator role oversees the entire ecosystem: onboarding new restaurants, monitoring the health of every Raspberry Pi edge device across every location, approving and deploying OTA software updates, and watching platform-wide analytics. This role is what makes centralized management of 400+ independently operating restaurants possible without a proportionally sized operations team.
Backend Services
A Node.js backend sits behind a load balancer, exposing REST APIs consumed by all three roles. It validates requests, manages authentication, reads and writes to the database, and — critically — publishes events to RabbitMQ rather than talking to restaurant hardware directly.
Cloud Infrastructure
Load-balanced virtual machines run the backend over HTTPS. Firebase provides authentication and the primary datastore (Firestore), with Google BigQuery receiving streamed analytics events for behavioral analysis.
IoT Devices
Every restaurant location has a dedicated Raspberry Pi 5 acting as an edge gateway. It subscribes to the RabbitMQ queue assigned to its restaurant, processes incoming order and update messages locally with Python, and communicates with thermal printers over the restaurant’s local network.
Key Takeaway: Three user roles, one shared cloud backbone, and a clean separation between cloud logic and edge hardware — this is the structural pattern that repeats through every layer of the platform described below.
Overall System Architecture
At a high level, the platform is organized into four layers, and the discipline of keeping them cleanly separated is what makes the system maintainable at 400+ locations.
┌────────────────────────────────────────────────────────────────────────────┐
│ FRONTEND LAYER │
│ Customer Ordering App │ Restaurant Admin Portal │ Super Admin │
│ (Next.js + TypeScript + Redux Toolkit + TanStack Query) │
└───────────────────────────────────┬────────────────────────────────────────┘
│ HTTPS
▼
┌────────────────────────────────────────────────────────────────────────────┐
│ CLOUD / BACKEND LAYER │
│ Load Balancer → Node.js REST API → Firebase Auth → Firestore │
│ Caching Aggregation Layer │ BigQuery Analytics │ AI Pipeline │
└───────────────────────────────────┬────────────────────────────────────────┘
│ Publish (AMQPS)
▼
┌────────────────────────────────────────────────────────────────────────────┐
│ COMMUNICATION LAYER │
│ RabbitMQ — per-restaurant queues, event-driven, durable messages │
└───────────────────────────────────┬────────────────────────────────────────┘
│ Subscribe (AMQPS)
▼
┌────────────────────────────────────────────────────────────────────────────┐
│️ EDGE LAYER (Per Restaurant) │
│ Raspberry Pi 5 (Python) → Printer Mapping → TCP → Kitchen Printer │
└────────────────────────────────────────────────────────────────────────────┘
Frontend Architecture
The customer-facing app, the restaurant admin dashboard, and elements of the super admin console are all built on Next.js with TypeScript. Redux Toolkit manages global application state (cart contents, session data, restaurant configuration), while TanStack Query handles server state — API data fetching, caching, and background refetching — which keeps the two concerns (client state vs. server state) from tangling into the kind of ad hoc state management that becomes unmaintainable as a dashboard grows.
Backend Architecture
The backend is a Node.js service exposing REST APIs. It performs request validation, authentication checks, business logic (menu rules, pricing, order state transitions), and persistence to Firestore. It is intentionally kept unaware of printer hardware, network topology at each restaurant, or device-specific quirks — all of that is pushed to the edge layer.
Cloud Components
Firebase supplies authentication and the primary document database. Load-balanced virtual machines run the backend so that traffic can be distributed across multiple instances rather than a single point of failure. Google BigQuery ingests streamed analytics events for behavioral analysis, separate from the transactional Firestore workload.
Communication Layer
RabbitMQ is the architectural hinge of the entire platform. Instead of the backend calling out to restaurant hardware synchronously, it publishes a message and moves on. Every restaurant has its own dedicated queue (or set of queues), and its Raspberry Pi subscribes only to the messages meant for it. This is what allows the cloud and the edge to fail independently — a printer jam at one restaurant, or a temporary internet outage at another, never propagates back into the backend or affects any other location.
Security
Communication between the backend and RabbitMQ, and between RabbitMQ and each Raspberry Pi, happens over AMQPS (AMQP over TLS), not plaintext AMQP. Customer-facing traffic runs over HTTPS. Printers are never exposed to the public internet — they’re only reachable from their local Raspberry Pi over the restaurant’s own local network, which removes an entire class of attack surface that a cloud-to-printer-direct architecture would otherwise expose.
Scalability Design
Because the backend never talks to hardware directly, it can be scaled horizontally behind the load balancer without any coordination with the edge layer. Because each restaurant’s Raspberry Pi only sees its own queue, adding restaurant number 401 doesn’t add load to restaurant number 1’s edge device or change its message volume. Both layers scale independently, which is the core property that let this platform grow 20x in location count without a 20x rewrite.
Best Practice: Design the boundary between your cloud backend and any physical hardware layer as an asynchronous message boundary, not a direct API call. It costs a small amount of additional complexity up front (you need a broker, and you need to think about message durability and acknowledgment) and it buys you independent scaling and independent failure domains—which is usually the difference between a system that degrades gracefully and one that cascades.
Full Stack Development Architecture
Next.js
Next.js was chosen for both the customer ordering experience and the restaurant/admin dashboards because it gives us server-side rendering where SEO and initial load time matter (the public-facing ordering pages) and a fast, app-like experience for authenticated dashboard views, from the same framework and the same TypeScript codebase.
TypeScript
Every frontend surface — customer app, restaurant admin, super admin — is written in TypeScript. On a platform with three distinct user roles, deeply nested order and menu data structures, and a growing engineering team, static typing catches an entire category of bugs (wrong field names, mismatched API contracts, incorrect assumptions about optional fields) before they reach a restaurant’s production dashboard.
Redux Toolkit
Redux Toolkit manages client-side application state: the current cart, UI state, active restaurant context, and session information. Its structured slice pattern keeps state logic predictable across a codebase touched by multiple engineers, which matters more as the team and the number of dashboard features grow.
TanStack Query
Server state — data that originates from the backend and needs caching, background refetching, and invalidation — is handled by TanStack Query rather than folded into Redux. This separation (client state in Redux Toolkit, server state in TanStack Query) avoids a common anti-pattern where API responses get manually copied into a global store and then drift out of sync with the server.
Responsive Dashboard
Restaurant admins and super admins need to check order status, printer health, and reports from a phone as often as from a desktop, particularly during service hours. The dashboard is built responsively from the same component library used in the customer app, rather than as a separate desktop-only tool.
Authentication
Authentication is handled through Firebase Authentication, with role-based access control layered on top so that a restaurant admin can only see and manage their own restaurant’s data, while a super admin has cross-restaurant visibility.
REST APIs
All frontend surfaces talk to the backend exclusively through versioned REST APIs. Keeping a clean REST contract between frontend and backend — rather than allowing dashboard-specific queries to bypass the API layer — is what makes it possible to build new frontend surfaces (a future mobile app, for instance) without duplicating backend logic.
Backend Engineering
Node.js
Node.js was a natural fit for this backend: an I/O-heavy workload (API requests, database calls, message publishing) with relatively light CPU-bound computation, running across many concurrent orders and dashboard requests. Its non-blocking I/O model handles this profile well, and it shares a language (TypeScript/JavaScript) with the frontend, which reduces context-switching for the engineering team.
REST APIs
The API surface is organized around resources — orders, menus, restaurants, devices, users — following conventional REST semantics. Each endpoint validates input, checks permissions against the requesting user’s role, and either reads from or writes to Firestore.
Database Design
Firestore’s document model maps naturally onto restaurant data: a restaurant document with nested or referenced menu items, an orders collection scoped by restaurant ID, and a devices collection tracking each Raspberry Pi’s identity and health status. Data is scoped per restaurant throughout, which keeps the multi-tenant boundary clean and makes it straightforward to reason about what a given restaurant admin should and shouldn’t be able to see.
Authentication
Firebase Authentication issues tokens that the backend verifies on every request. Role claims (customer, restaurant admin, super admin) are attached to each authenticated session and checked against the resource being accessed, rather than relying on the frontend to enforce access control.
Event Processing
Rather than performing every downstream action synchronously inside the request/response cycle, the backend treats certain actions — most importantly, dispatching an order to a restaurant’s hardware — as events to be published to RabbitMQ. This keeps API response times fast and decouples “the order was accepted” from “the order was printed,” which are genuinely different concerns with different reliability requirements.
API Security
All traffic runs over HTTPS. Firebase Authentication tokens are required on every authenticated route. Backend-to-RabbitMQ and RabbitMQ-to-device communication uses AMQPS. Rate limiting and input validation sit in front of business logic to reduce the attack surface presented by a public-facing ordering API.
Distributed Systems Using RabbitMQ
Why Message Queues
The single biggest architectural lesson from this project is this: once your backend needs to talk to physical hardware in hundreds of independent locations, a direct connection model breaks down. A direct HTTP call from the backend to a restaurant’s printer controller requires that controller to be reachable from the cloud (a security problem), available at the exact moment the call is made (a reliability problem), and fast enough not to block the request (a latency problem). None of those three properties can be guaranteed across 400 independently operated local networks.
RabbitMQ removes all three constraints. The backend publishes a message and considers its job done. The message sits durably in a queue until the relevant Raspberry Pi is ready to receive it — whether that’s 50 milliseconds later or, after a brief connectivity drop, several minutes later.
Event Driven Architecture
Orders are represented as structured messages — an order event tagged with the restaurant and order ID — published to the queue associated with that restaurant. The Raspberry Pi at that restaurant subscribes only to its own queue(s), so it never receives, and never needs to filter out, traffic belonging to any other location. The same pattern extends to OTA update notifications, remote command execution, and IP scan requests — different message types, same queue-based delivery model, which is the pattern documented in the Hopa-Print architecture: a single message-type dispatcher on the device side routes each incoming message to the correct handler (print job, update, custom command, or connectivity flow).
Fault Tolerance
If a Raspberry Pi is temporarily offline — a router reboot, a power flicker, a connectivity drop — messages simply wait in the queue. Nothing is lost, and no customer-facing request fails because of a hardware issue three time zones away. RabbitMQ’s acknowledgment model means a message is only removed from the queue once the receiving device confirms it was processed successfully; an unacknowledged message is redelivered, so a Raspberry Pi that crashes mid-print doesn’t silently drop the order.
Horizontal Scaling
Because each restaurant has its own queue, adding a new restaurant is additive rather than disruptive — it doesn’t require touching the configuration or capacity planning for any existing restaurant’s queue. This is what let the platform grow from roughly 20 to more than 400 locations without a redesign of the messaging layer itself.
Queue Management
Operationally, per-restaurant queues also make troubleshooting tractable: if a single location reports missed orders, the platform team can inspect that restaurant’s queue depth and message history in isolation, rather than sifting through a single shared queue carrying traffic for every restaurant on the platform.
Common Mistake : Treating a message queue as "just a slower API call." A queue is not a replacement for a request/response API — it's a deliberate design choice to decouple two systems that shouldn't be forced to be available and fast at the same time. Teams that bolt a queue onto a system without changing their mental model (e.g., blocking and waiting for the eventual response) usually don't get the reliability benefits they were hoping for.
IoT Edge Computing with Raspberry Pi
Edge Computing
Edge computing, in this platform, means one specific thing: hardware-facing logic runs on a device physically located at the restaurant, not in the cloud. This isn’t a trend-following choice — it’s a direct response to the fact that kitchen printers are local, latency-sensitive, and shouldn’t be reachable from the public internet.
Raspberry Pi Architecture
Every restaurant runs a dedicated Raspberry Pi 5 as its edge gateway. In the related Hopa-Print system, the device stack is intentionally lightweight: a Bash layer for installation, service management, and system operations (install.sh, uninstall.sh, printer_runner.sh, health.sh), a Python service that owns the RabbitMQ connection and business logic, and a Node.js service — using headless Chrome — dedicated purely to rendering receipt HTML into a printable image. Two cron jobs run continuously on the device: a health check every two minutes and an update check every minute, giving the platform team near-real-time visibility into every device’s status without polling from the cloud side.
Offline Processing
If internet connectivity drops, the Raspberry Pi doesn’t stop working — it queues incoming orders locally (backed by RabbitMQ’s own durability once connectivity resumes) and continues serving the restaurant’s local printing needs where possible, rather than taking the kitchen offline because of a cloud dependency.
Printer Communication
Printer identity and mapping is handled at the edge. The device determines which physical printer — by MAC address or IP — should receive a given order, based on configuration synced to the device, rather than the cloud needing to know the physical network layout of every restaurant kitchen.
TCP Communication
Once the correct printer and receipt image are determined, the final delivery step is a TCP connection from the Raspberry Pi to the printer over the restaurant’s local network — a short, local, low-latency hop that never touches the public internet.
Local Processing
The full local pipeline — as documented in the Hopa-Print architecture — looks like this: the Python service receives a print job from RabbitMQ, hands the order’s HTML content and a temp file path to the Node.js service, which launches headless Chrome (via Puppeteer) to render the receipt into an image and save it to the file system. The Python service then reads that image back, sends it to the mapped printer over TCP, and — only after receiving print confirmation — acknowledges the original message back to RabbitMQ, removing it from the queue.
RabbitMQ Queue → Python Service → Node.js Service → Headless Chrome
│ │
│ │
│ Generate & save receipt image
│ │
│ │
└────────────── Python reads image ◄───────────────┘
│
│
Send image to Printer (TCP)
│
│
Printer confirms print
│
│
Python acknowledges message → RabbitMQ (message removed)
Key Takeaway : The acknowledgment only fires after the printer confirms the job — not after the message is received. That single design detail is what prevents "lost tickets": if the device crashes between receiving the message and confirming the print, RabbitMQ redelivers it instead of assuming success.
Order Processing Flow
It’s worth walking through the complete path of a single order end to end, because every architectural decision described above exists to serve this exact flow reliably, thousands of times a day, across 400+ independent locations.
- Validate order
- Fetch restaurant configuration (Firebase / Cache)
- Store order (Firestore)
- Publish event (AMQPS)
- Receive message (AMQPS)
- Resolve printer mapping
- Request receipt image (Node.js + Headless Chrome)
- Printer confirms print
- Pi acknowledges the message
- RabbitMQ removes the message from the queue
Step by step:
- Customer places an order through the Next.js frontend. The request is sent over HTTPS.
Load Balancer receives the request first and distributes it across multiple backend virtual machine instances, so no single server becomes a bottleneck.
Backend (Node.js) validates the order, retrieves the restaurant’s configuration (menu, printer mapping, pricing rules — served from cache where possible), and writes the order to the database.
Instead of contacting restaurant hardware directly, the backend publishes an event to RabbitMQ over AMQPS, structured as an order message tagged with the order ID.
RabbitMQ routes the message to the queue dedicated to that specific restaurant.
The restaurant’s Raspberry Pi, subscribed only to its own queue, receives the message and processes it locally with Python.
The Pi resolves which kitchen printer should receive the order based on its local printer mapping, requests a rendered receipt image from its local Node.js/headless Chrome service, and sends the finished image to the printer over TCP on the local network.
Once the printer confirms the job, the Pi acknowledges the message back to RabbitMQ, and the order is marked complete — removed from the queue and reflected back in the restaurant admin dashboard.
The entire flow, from tap to printed ticket, typically completes in a small number of seconds — and critically, a slowdown or failure at any single restaurant’s hardware layer has no effect on the backend, the load balancer, or any other restaurant’s order flow.
Cloud Infrastructure
Virtual Machines
The backend runs on load-balanced virtual machines rather than a single server instance. This allows horizontal scaling — adding more instances as order volume grows — instead of vertical scaling, which has a hard ceiling and a much higher blast radius when something goes wrong.
Load Balancer
Every request hits the load balancer before it reaches a backend instance. Beyond simple traffic distribution, this gives the platform the ability to take individual instances out of rotation for maintenance or after a failed health check, without any customer-visible downtime.
HTTPS
All customer, restaurant admin, and super admin traffic is encrypted end to end over HTTPS. This isn’t just a compliance checkbox — with payment-adjacent order data flowing through the system, encryption in transit is a baseline requirement.
High Availability
High availability here comes from the combination of multiple backend instances behind a load balancer, RabbitMQ’s durable, acknowledgment-based message delivery, and the edge layer’s ability to keep functioning locally during brief connectivity interruptions. No single component failure — a backend instance, a restaurant’s internet connection, or an individual printer — is capable of taking down the platform.
Scalability
Scalability is designed in at every layer independently: the backend scales by adding VM instances behind the load balancer; RabbitMQ scales by adding restaurant-specific queues, which is inherently linear and additive; and the edge layer scales simply by shipping another Raspberry Pi to the next restaurant being onboarded — none of these require touching the other layers.
AI Development in Restaurant Automation
AI OCR
Restaurant onboarding used to be one of the slowest parts of adding a new location: someone had to manually type in every menu item, category, price, and description — often from a PDF, a photograph of a printed menu, or a spreadsheet in a regional language. We built an AI-powered menu processing pipeline that takes an uploaded menu document and extracts structured data — categories, item names, prices, and descriptions — using OCR combined with a language model to interpret and structure the extracted text.
Menu Processing
Once extracted, the AI system organizes items into the platform’s menu hierarchy and imports them directly into the restaurant management system, ready for a restaurant admin to review rather than build from scratch.
Smart Categorization
Items are automatically grouped into sensible categories (starters, mains, beverages, desserts) based on the extracted content, rather than requiring a restaurant admin to manually classify every item — a task that scales poorly across menus with hundreds of items.
Automation
The combined effect is that onboarding a new restaurant’s menu goes from a multi-day manual data-entry task to a review-and-approve workflow, which matters directly when the business objective is adding new locations quickly.
Business Benefits
Fewer manual entry errors, faster time-to-launch for new restaurant locations, and less dependency on a data-entry team that would otherwise need to scale linearly with the number of new restaurants being onboarded each month.
Best Practice: Apply AI where it removes genuinely repetitive human work with a clear, checkable output (structured menu data that a human reviews before publishing) rather than where it makes an unsupervised decision that directly reaches the customer. Menu digitization is a strong fit for this pattern; fully autonomous pricing or menu changes would not be.
Multi Language Platform
Localization
Restaurants on the platform operate across different regions and languages, and both customers and restaurant staff need to interact with the system in their own language — not just a translated UI shell, but menus, item descriptions, and notifications that read naturally.
Internationalization
On the frontend, rather than calling a translation API on every page load for every customer, the platform uses localized language files bundled with the application. This trades a small amount of translation flexibility for a large gain in page load performance and a large reduction in ongoing API costs — a reasonable trade for content (UI strings) that doesn’t change often.
Google Translate API
For dynamic, frequently changing content — restaurant menus, in particular — the backend integrates the Google Translate API, giving restaurant admins a fast way to translate a menu into additional languages with minimal manual effort, which is then reviewed and published rather than served untranslated in real time to every customer request.
This hybrid approach — static localization files for UI, on-demand translation for dynamic content, reviewed before publishing — balances performance, cost, and translation quality better than either extreme (fully static or fully real-time) would alone.
Big Data & Analytics
Google BigQuery
Beyond order processing, the platform streams behavioral events into Google BigQuery, kept deliberately separate from the transactional Firestore workload so that analytical queries — which tend to scan large amounts of historical data — never compete with or slow down live order processing.
User Behaviour
Event streams capture how customers actually move through the ordering experience: which menu categories get opened, which items get added to a cart and then removed, and where in the flow customers abandon an order — all of which is difficult to infer from order data alone, since order data only reflects completed transactions.
Heatmaps
Aggregated interaction data can be visualized as heatmaps across menu categories and items, giving restaurant admins a direct view of which parts of their menu customers actually engage with, as distinct from which parts they merely purchase.
Analytics
Analytics extends to anomaly detection — flagging unusual patterns, such as a location experiencing an unexpected drop in orders (which may indicate a technical problem, such as a printer or connectivity issue, well before a customer complaint or a support ticket surfaces it).
Customer Journey
Stitching together events from first menu view through to order completion gives a full picture of the customer journey, which is the raw material for product decisions — where to simplify a flow, where checkout friction is costing conversions, and which features restaurant admins actually use.
Business Intelligence
The combination of BigQuery analytics and Firestore transactional data gives both the platform team and individual restaurant operators data-backed answers to operational questions, replacing intuition with evidence — which items to promote, which locations need operational attention, and where the ordering experience itself needs improvement.
Intelligent Caching Strategy
This section covers one of the more consequential production lessons from the entire project.
As the platform grew past a few hundred locations, the backend was performing nearly 12 million Firestore read operations every single day — restaurant configuration, menu data, printer mappings, and visitor session data, fetched fresh on nearly every request. Firebase costs scaled directly with location count and traffic, to the point where infrastructure cost was becoming a real business concern rather than a rounding error.
The instinct in this situation is often to start optimizing individual queries — smaller documents, more selective fields, better indexes. We took a different approach: we introduced a Caching Aggregation Layer in front of Firestore for frequently accessed, infrequently changing data — restaurant configuration, menus, and printer mappings chief among them.
The results:
| Metric | Before Caching | After Caching | Improvement |
|---|---|---|---|
| Firestore reads/day | ~12 million | ~2.4 million | ~80% reduction |
| Firebase infrastructure cost | Baseline | ~20% of baseline | ~80% reduction |
| Backend response time | Baseline | Faster | Reduced database round-trips |
| Backend load | Baseline | Lower | Fewer downstream calls per request |
The insight here generalizes well beyond this specific platform: sometimes the highest-leverage optimization isn’t writing faster code — it’s not making the database call in the first place. Restaurant configuration doesn’t change every second; there’s no reason to fetch it from a live database on every single order.
Key Takeaway : Before optimizing a query, ask whether the data being queried actually needs to be fetched fresh at all. A caching layer for stable, frequently read data is often a bigger win than any amount of query tuning.
Common Mistake : Caching everything indiscriminately, including data that changes frequently (like live order status), which introduces stale-data bugs that are far more expensive to debug than the database cost the cache was meant to save. Cache what changes rarely; leave what changes often uncached, or cache it with a short, deliberate TTL.
Secure OTA Update Pipeline
Remote Updates
With hundreds of Raspberry Pi devices distributed across independently operated restaurant locations — many without on-site technical staff — manual software updates were never a viable long-term operating model. The platform includes a secure Over-The-Air (OTA) update pipeline built specifically for this constraint.
Zero Downtime
The design goal was explicit: an update should never cause a restaurant to lose an incoming order. During installation, any customer orders that arrive are temporarily stored safely on the device rather than dropped, and processing resumes automatically the moment the update completes.
Rollback
If validation of a downloaded update fails — a corrupted package, a failed installation step — the device automatically reverts to the last known-good version rather than being left in a broken state that would require someone to physically visit the restaurant.
Version Control
Each device tracks its currently installed version against the latest available version. A lightweight cron job (running every minute in the Hopa-Print device architecture) checks for a version mismatch and triggers the update flow only when one is detected — rather than the cloud pushing updates blindly to every device on a schedule.
Device Management
The full OTA workflow, as implemented across the platform’s edge devices, runs as follows:
Step-by-step OTA workflow:
Super Admin uploads a new software release package through the platform admin console.
Backend validates the release (integrity checks, versioning) before it becomes available for deployment.
Update notification published through RabbitMQ, addressed to the relevant device queue(s).
Raspberry Pi receives the notification via AMQPS and downloads the update package.
Backup created — the device backs up its current running version (src → src_2) before touching anything.
Package extracted. If extraction fails, the device automatically reverts the changes, removes the partial new version, and restores the backup — exiting cleanly with an error state rather than a broken install.
Configuration preserved — the device’s local device.config is copied forward into the new version so device-specific settings survive the update.
Installer runs, applying the new version.
Verification. If the new version passes verification, it replaces the previous one; if not, automatic rollback restores the last stable backup.
Cleanup — the downloaded package and update-state file are removed, and the device service restarts on the new version.
Queued orders resume processing automatically, with nothing lost during the update window.
New src → Run installer.sh
This is what makes OTA deployment across hundreds of geographically distributed devices operationally realistic instead of a maintenance nightmare: no engineer needs to touch a device individually, failures are self-healing by default, and in-flight customer orders are never the cost of a software rollout.
Best Practice : Any OTA system for field-deployed hardware should treat "the update failed" as an expected case to design around, not an edge case to handle later. Automatic backup-before-update and automatic rollback-on-failure should be there from the first version of the pipeline, not added after the first device gets bricked in production.
Engineering Lessons Learned
Several lessons from this project generalize well beyond restaurant software, and apply to any team building distributed, hardware-connected platforms:
Reliability. Reliability isn’t a property you add at the end — it comes from architectural choices made early: message acknowledgment instead of fire-and-forget, automatic rollback instead of hoping an update works, and independent failure domains between the cloud and every piece of physical hardware.
Scalability. Horizontal scaling only works cleanly when each layer can scale without coordinating with the others. Per-restaurant RabbitMQ queues, stateless backend instances behind a load balancer, and edge devices that only know about their own restaurant are all expressions of the same principle.
Cloud Native Design. Keeping the backend hardware-agnostic — no direct knowledge of printer models, local network topology, or device-specific quirks — meant cloud infrastructure could evolve (different hosting, different scaling strategy) without touching the edge layer, and vice versa.
Fault Tolerance. A restaurant losing internet connectivity, a printer jamming, or a backend instance restarting should each be a contained, recoverable event — not a cascading failure. Every layer of this platform was explicitly designed against that standard.
Edge Computing. Pushing hardware-specific logic to the edge — rather than centralizing it in the cloud — reduces latency, removes a security liability (printers reachable from the internet), and keeps restaurants operational during connectivity interruptions.
Distributed Systems. Asynchronous, message-driven communication between services that don’t need to be tightly coupled is what let this platform grow by more than 20x in location count without a corresponding rewrite of its core architecture.
Business Impact
Technology decisions only matter to the extent they move a real business metric. Here’s what this architecture translated to in practice:
Growth from ~20 restaurants to 400+ locations on the same core architecture, without a platform rewrite.
~80% reduction in Firebase/Firestore infrastructure costs, driven entirely by the caching aggregation layer.
Faster restaurant onboarding, through AI-assisted menu digitization replacing manual data entry.
Remote device management across hundreds of Raspberry Pi edge devices, with no on-site technical visits required for routine operations.
Automated, zero-downtime software deployment to the entire device fleet through the OTA pipeline.
Improved operational reliability, with printer and connectivity issues contained to individual restaurants rather than affecting the platform.
Data-driven product decisions, enabled by BigQuery-based behavioral analytics separate from transactional load.
The most consequential part of this project wasn’t any single feature — it was building an architecture that kept absorbing 20x growth without requiring a proportional increase in engineering effort or operational headcount. That’s the actual measure of good platform engineering.
Why Enterprises Choose Krishworks
Enterprises, restaurant chains, manufacturers, and logistics companies come to Krishworks Technology Innovations for the same underlying reason: they have a system that needs to work reliably across physical locations, physical hardware, and real operational pressure — not just in a controlled demo environment.
Enterprise Software. We design backend systems and dashboards around real multi-tenant, role-based operational needs — not a single-user prototype scaled up after the fact.
IoT. As an IoT development company, we cover the full stack from hardware selection and firmware through edge software and cloud integration, which matters when a project (like a restaurant printer network) genuinely spans a circuit board and a cloud backend in the same sprint.
AI. We apply AI where it removes real, repetitive manual work with a checkable output — menu digitization, document processing, anomaly detection — rather than treating it as a headline feature disconnected from the operational problem.
Cloud. Our cloud architecture practice is built around independent scaling and failure isolation between layers, drawing directly from experience running production systems across hundreds of distributed locations.
Full Stack. One team, one codebase discipline (TypeScript across frontend and backend), covering customer-facing apps, internal dashboards, and the APIs that connect them — which avoids the coordination overhead of stitching together separate frontend and backend vendors.
Industrial Automation. The same architectural patterns behind restaurant kitchen printing — edge gateways, message queues, OTA device management — apply directly to industrial IoT, asset tracking, and manufacturing telemetry, which is a meaningful share of our client base outside restaurant technology.
Technology Stack
| technology | purpose | benefits | business value |
|---|---|---|---|
| Next.js | Frontend framework for customer app and admin dashboards | Server-side rendering, fast load times, unified React/TypeScript codebase | Better SEO for customer-facing pages, faster feature delivery |
| TypeScript | Static typing across frontend and backend | Catches contract mismatches and bugs before production | Fewer production incidents, easier onboarding for new engineers |
| Redux Toolkit | Client-side application state management | Predictable, structured state logic | Maintainable dashboards as feature count grows |
| TanStack Query | Server state management and caching | Automatic caching, background refetching, cache invalidation | Fewer redundant API calls, more responsive UI |
| Node.js | Backend REST API service | Non-blocking I/O suited to high-concurrency, I/O-heavy workloads | Handles concurrent order volume efficiently |
| RabbitMQ | Message broker between cloud and edge devices | Asynchronous, durable, acknowledgment-based delivery | Independent failure domains; no single restaurant can affect another |
| Firebase (Auth + Firestore) | Authentication and primary transactional database | Managed auth, flexible document model | Faster development, reduced operational overhead |
| Python | Edge device business logic (Raspberry Pi) | Strong hardware/IoT ecosystem, simple to maintain | Reliable local order and printer processing |
| Raspberry Pi 5 | Restaurant edge gateway hardware | Low-cost, low-power, capable of local compute and networking | Cost-effective per-location hardware footprint |
| Google BigQuery | Analytics data warehouse | Handles large-scale analytical queries without affecting transactional load | Data-driven product and operations decisions |
| AI / OCR pipeline | Menu digitization and structuring | Converts unstructured menu documents into structured data | Faster restaurant onboarding, fewer manual entry errors |
| DevOps / OTA Pipeline | Remote device deployment and update management | Automated rollout with backup and rollback | Zero-downtime updates across hundreds of devices |
| Edge Computing | Local processing on restaurant hardware | Low latency, offline resilience, reduced attack surface | Continued operation during connectivity interruptions |
Future of AI + IoT + Full Stack Development
AI Agents
The next iteration of AI in restaurant platforms is likely to move beyond one-shot document processing (like menu digitization) toward agents that handle multi-step operational tasks — reconciling inventory against sales data, drafting menu pricing recommendations, or triaging device health alerts before they become support tickets — with a human still reviewing the output before it takes effect.
Industrial IoT
The architectural pattern used here — edge gateway, message queue, cloud backend — is directly transferable to industrial IoT: factory floor sensors, cold-chain logistics monitoring, and equipment telemetry all follow the same shape, where local hardware needs to keep working independent of cloud connectivity and report back asynchronously.
Predictive Analytics
As BigQuery-based behavioral data accumulates over longer time horizons, the opportunity shifts from descriptive analytics (“what happened”) to predictive analytics (“what’s likely to happen”) — forecasting order volume by location and time of day, or flagging a device that’s showing early signs of failure before it actually goes offline.
Edge AI
Running lightweight inference directly on edge devices — rather than only in the cloud — is a natural next step for restaurant hardware: local anomaly detection on printer behavior, for instance, without needing a round trip to the cloud for every signal.
Digital Twins
For multi-location operators, a digital twin of each restaurant’s hardware and operational state — device health, printer status, queue depth — gives operations teams a live, queryable model of the physical estate, rather than reconstructing it from logs after something goes wrong.
Autonomous Operations
The long-term direction is toward more autonomous operational handling: self-healing device fleets (already partially true here, through automatic OTA rollback), automated capacity scaling driven by real-time order volume, and AI-assisted anomaly response that flags and, in low-risk cases, resolves issues without waiting for a human operator.
Future Trends
Across restaurant technology, industrial automation, and logistics, the direction is consistent: more intelligence pushed to the edge, tighter feedback loops between physical operations and cloud analytics, and infrastructure that assumes failure as a normal condition to design around rather than an exception to react to.
Conclusion
The engineering story behind scaling a restaurant platform from 20 to 400+ locations isn’t really about any single technology. Next.js, Node.js, RabbitMQ, Raspberry Pi, and BigQuery are all reasonable, well-understood tools — the actual engineering work was in the decisions connecting them: publishing events instead of calling hardware directly, caching aggressively where data is stable, designing OTA updates around automatic rollback rather than hoping deployments succeed, and keeping every layer independently scalable and independently failable.
That’s the same set of decisions that shows up whenever a business needs software connected to physical operations at scale — restaurant chains, manufacturers, logistics networks, and industrial operators alike. If your team is running into the same category of problems — hardware that needs to stay reliable across many locations, a cloud bill growing faster than your user base, or a device fleet that’s outgrown manual management — this is exactly the kind of architecture problem we work on.
Krishworks Technology Innovations designs and builds custom software, AI, IoT, cloud, and enterprise application systems for businesses that need their technology to hold up under real production conditions. If you’re evaluating how to architect a platform like this — or scale one you’ve already built — get in touch with our engineering team to talk through your architecture.
About Krishworks Technology Innovations
Who We Are
Krishworks Technology Innovations is a software and IoT development company headquartered in Bengaluru, Karnataka, with an engineering presence in Whitefield and a second delivery office in Kolkata. We work across enterprise software development, custom IoT hardware and firmware, AI/ML systems, and full stack web and mobile applications, and we’re incubated out of the IIM Calcutta Innovation Park ecosystem.
Our engagements tend to sit at the intersection of physical hardware and cloud software — restaurant kitchen printers talking to RabbitMQ queues, industrial sensors streaming telemetry to a dashboard, Raspberry Pi devices receiving OTA updates in the field. That combination — firmware, edge computing, backend engineering, and cloud architecture under one roof — is unusual, and it’s the reason clients bring us projects that involve both a circuit board and a Kubernetes-adjacent cloud deployment in the same sprint.
Enterprise Software Development
We build backend systems, admin dashboards, and customer-facing applications for clients who need software that behaves predictably at scale — not just in a demo, but under real production load with real operational constraints: multi-tenant data isolation, role-based access for different types of users (customers, location managers, and platform administrators), audit trails, and uptime guarantees.
IoT Development Services
As an IoT development company, we design and ship the full stack of a connected device: PCB and hardware selection, firmware, edge software (typically Python or C on Raspberry Pi, ESP32, or similar boards), device provisioning, remote management, and the cloud services that receive and act on device data. Our device catalog spans sensors (accelerometer, temperature, humidity, GPS), connectivity protocols (BLE, LoRaWAN, MQTT, Zigbee, 4G LTE), and edge gateway hardware — which is exactly the toolkit a restaurant printer network, an asset-tracking deployment, or an industrial monitoring system draws from.
AI Development Services
Our AI work is generally applied, not exploratory: OCR and document-structuring pipelines (as used for AI-assisted menu digitization), computer vision, and anomaly detection layered on top of the analytics pipelines we already operate for clients. We treat AI as a way to remove repetitive manual work — data entry, categorization, translation review — rather than as a headline feature bolted onto a product.
Edge Computing Solutions
Edge computing is where our IoT and backend engineering practices meet. When a client needs devices that keep working during an internet outage, need sub-second local response times, or must not expose hardware like printers or industrial controllers directly to the public internet, the answer is almost always an edge gateway architecture — a local compute device (commonly a Raspberry Pi) that talks to hardware locally and to the cloud asynchronously, through a message queue rather than a direct connection.
Digital Transformation Expertise
Across restaurant chains, manufacturers, and logistics operators, the pattern we see repeatedly is the same: a business that has outgrown spreadsheets, manual processes, and point solutions, and needs a single platform connecting its physical operations to real data. That’s the practical definition of digital transformation we work from — not a slogan, but a specific set of systems: identity and access management, device fleets, event pipelines, and analytics that let decision-makers see what’s actually happening across dozens or hundreds of locations.
FAQs
Have Questions? We’re here to help.
A production-scale IoT restaurant platform connects cloud applications, edge devices, kitchen printers, and analytics into a single ecosystem. When a customer places an order, the system securely processes it through cloud services, message queues, and Raspberry Pi edge devices before printing it in the kitchen. This architecture ensures scalability, reliability, and uninterrupted operations across hundreds of restaurant locations.
RabbitMQ enables asynchronous communication between cloud services and IoT devices. Instead of directly communicating with restaurant hardware, the backend publishes messages to a queue, allowing Raspberry Pi edge devices to process them independently. This improves fault tolerance, prevents data loss, and allows the platform to scale efficiently without affecting customer experience.
Edge computing processes data close to where it is generated instead of relying entirely on cloud servers. In this platform, Raspberry Pi devices manage kitchen printers, local order queues, and device health monitoring. This reduces latency, improves reliability, and allows restaurants to continue operating even during temporary internet outages.
Raspberry Pi serves as an intelligent edge gateway between cloud infrastructure and local hardware. It securely receives orders, communicates with kitchen printers, monitors device health, stores data locally during connectivity issues, and supports OTA software updates. This makes it an ideal solution for scalable IoT and Industrial IoT deployments.
AI simplifies restaurant onboarding by automatically extracting menu items, categories, descriptions, and prices from uploaded documents. Instead of manually entering hundreds of items, restaurant managers simply review and approve AI-generated data. This reduces onboarding time, minimizes errors, and improves operational efficiency.
Over-the-Air (OTA) updates allow software to be remotely deployed to IoT devices without physical access. The platform safely downloads updates, verifies installation, and automatically rolls back if any issue occurs. This ensures secure, zero-downtime software updates across hundreds of distributed Raspberry Pi edge devices.
Caching stores frequently accessed information such as menus, restaurant configurations, and printer mappings in memory instead of repeatedly querying the database. This significantly reduces database reads, lowers cloud infrastructure costs, improves application performance, and enables the platform to handle higher traffic efficiently.
Modern IoT platforms combine Full Stack Development, cloud infrastructure, and edge computing technologies. This project uses Next.js, Node.js, TypeScript, RabbitMQ, Firebase, Google BigQuery, Raspberry Pi, Python, REST APIs, and AI-powered automation to build a secure, scalable, and production-ready enterprise solution.
Direct cloud-to-device communication depends on constant internet connectivity and publicly accessible hardware. Edge computing eliminates these limitations by allowing local devices to process data independently while synchronizing with the cloud asynchronously. This improves security, reduces latency, and increases system reliability.
Hardware/PCB design & addon services
