Modernizing the Architecture of Quick Serve Restaurant (QSR) Infrastructure
Authors: Daniel Villanueva, Ian Lowrie, Kimberly Davis, Vicky Milhoan, and David Hibler
Managing a Quick Serve Restaurant (QSR) increasingly means managing sophisticated computing technology. On the one hand, brands are automating kitchen and ordering processes to save on labor costs, avoid order errors, and decrease food waste. On the other, their customers increasingly expect easy-to-use, delightful, cutting-edge experiences at the drive-thru and in the dining area. Whether it is an automated drive-through powered by conversational AI or an inventory management system using predictive analytics, new technologies come with new challenges.
This short paper details how a modern, container-based software engineering approach to building QSR infrastructure can create the opportunities for brands, system integrators (SIs), and independent software vendors (ISVs) to integrate, manage, and orchestrate these new application workloads more quickly and cheaply, leading to better experiences for restaurant operators, employees, and customers.
The Business Challenge
We’ve spent a lot of time talking with QSR brands about their digital transformations and about a few main challenges. For brands just getting started on their transformation journey, it’s difficult to know which solutions will provide genuine value, where and how to start integrating new technologies, and how best to manage the infrastructure cost for maximum ROI. For brands a bit further along, the expertise and effort required to integrate multiple independent applications and manage the complex infrastructure needed can quickly become overwhelming.
In large part, this seems to be because many contemporary QSR software solutions come as piece-by-piece, standalone, usually monolithic applications rather than comprehensive overall solutions for QSRs.[1]
For example, today’s restaurants may use modern point of sale (POS) applications, but it can be challenging to integrate that POS application tightly with an order verification or customer analytics solution. While this patchwork approach does allow brands and SIs substantial flexibility to choose exactly the right software for their needs, it can be difficult and costly to get these applications to play well together. These disjointed collections of applications also pose user experience challenges for both workers and customers along every stage of the digital transformation journey. Moreover, application-siloed data also precludes QSR technology and operations leaders from obtaining insights that could be available from a holistic view of their information.
QSRs struggle to manage their infrastructure, often a combination of public or private cloud services, edge compute such as workstations or servers, and purpose-built computing devices such as in kiosks, digital menu boards, or POS machines. This heterogeneous computing environment can be costly and brittle, preventing visibility and software integration.[2]
This paper outlines a design that suggests a way to move beyond these problems for brands, SIs, and the ISVs that serve them.
The Idea
The goal of this paper is to sketch out an approach that could allow QSRs, alongside solution integrators and software vendors who work with them, to build easily modifiable and interoperable solutions that can run easily either at the edge or in the cloud. The architectural approach here uses mostly open-source microservices running on Kubernetes clusters, which are then united by the publish-subscribe model of the MQ Telemetry Transport (MQTT) message bus. This message bus can be developed around a variety of different events or use cases in the restaurant, such as customer ordering, inventory depletion, restock, lobby management, etc.
This hypothetical example takes the use case of Automatic Speech Recognition-powered voice ordering at the drive-thru or a lobby kiosk to illustrate the more general principles behind this publish-subscribe model. In this example, the various steps in handling a customer order become recognizable, standard messages that can be passed around to a variety of nodes on the MQTT bus, simplifying the roll-out of a unified but modular QSR architecture and making it easier to solve customer and business problems with AI solutions.
The design has three main components:
- A building block-style architecture of customizable, open-source infrastructure components
- Pre-trained automatic speech recognition models, such as those provided by the Intel® Distribution of OpenVINO™ toolkit
- Hypothetical QSR user applications (the “Order Receiver,” “Custom Order Display,” and “Employee Order Display”) to help envision how this architecture might work in practice.
The Design
Figure 1 demonstrates the high-level approach to a containerized microservice architecture for use in QSRs, with these service layers:
- Infrastructure: containerized services and run-time
- Core: speech-to-text functionality, display coordination, and user-friendly container management
- Message Bus: publish-subscribe message bus for senders and receivers
- Applications: QSR user applications
We have explored this approach using a network topology of several Intel-based systems attached to a network router, though other hardware or hybrid infrastructure could work as well. In either case, this infrastructural approach allows QSRs brands and vendors to choose the compute that works best for them — ranging from ultra-lightweight processors in drive-thru podiums, through rugged servers handling kitchen operations, to entirely cloud-based solutions. (Please note, though, that the use of a simple network topology and configuration would be the quickest way to set up a sandbox to explore this new approach.)
The flexibility of Kubernetes makes the ideal substrate for this approach. Kubernetes abstracts away the actual computing hardware, allowing microservices or application-level workloads to flexibly use resources from any of the systems in the network topology.
Figure two gives a “textbook” example of how Kubernetes organizes these workloads, just for a bit more context.
Kubernetes-based architecture is a great way to solve a range of infrastructural and software challenges facing today’s QSR technologists. Kubernetes is quickly becoming a wide-spread standard for container orchestration. It offers a wealth of tools for visibility and manageability, allowing IT professionals to quickly understand and maintain their network and computing infrastructure. An added bonus is that the Kubernetes ecosystem provides most of the necessary services as open-source offerings. This example uses a K3s distribution, but any standards compliant distribution should work equally well. K3s has the advantage of being designed for lower overhead and is easily deployable at edge sites.
This example uses the following services. How they interact is detailed more in the following section. Feel free to skim this section and return as necessary to understand the details.
The Message Path
Let’s walk through how these components interact with one another in a hypothetical QSR stack. The following diagram and associated list outline a customer order and the path the related messages take through the publish-subscribe model in the architecture. Note that the approach allows for the flexibility to incorporate a variety of response modalities here: you could incorporate a Text-to-Speech module that would reply verbally to the ordering customer, have responses display on a kiosk, or loop in a real human to reply.
Here’s a diagram that outlines a proof-of-concept architecture for automated drive-thru or kiosk ordering using Automatic Speech Recognition.
- Audio is received from drive-thru microphone, a message labeled “Voice Order” is published on to the bus
- ASR receives “Voice Order” message and processes audio.
- ASR publishes “Structured Order” message containing a list of order items
- Order Receiver listens for “Structured Order” and does some post processing if needed (“Free Fry with Drink Order”)
- Order Receiver publishes a “Order Display” message
- Display Composer receives the “Order Display” message and does some post processing if needed
- Display Composer publishes “Customer Display” and “Employee Display” messages.
- Customer and Employee Order Display listen to respective messages and output display.
This is just an illustrative example: the decoupling of implementation and data in this approach makes it easy to add on other services or features as well. For example, you could now easily add another service that listens for “Structured Order” messages and determines most popular items during a given time frame — without requiring any changes to existing code and services. If you need to add a new Customer Display or Employee Display, you can just add it to the bus and the displays would automatically get updates without any changes required to the Display Composer service or to the Display Receiver code. Similarly, the MQTT message bus makes it easy to create new “messages” for additional use cases, such as inventory management or order verification, and to quickly integrate new applications into a holistic restaurant management platform.
Summary and Next Steps
Our approach to modern application integration and infrastructure management is centered on the idea of a publish-subscribe message bus. For Quick Serve Restaurants, this approach allows real tasks such as ordering or inventory replenishment to be quickly registered by various modular applications, such as an “Order Receiver” or an “Employee Order Display.” These applications would then take the appropriate actions and publish their results back to that message bus. Using an IoT automation solution such as Intel® Edge Conductor, this approach might ultimately allow the automation of a broad range of routine kitchen tasks.
In testing of this approach, we have used mostly Intel® 11th-generation i7 NUC systems in our network topology, which enabled us to leverage an ASR module that incorporated the optimized models available from the Intel® Distribution of OpenVINO™ Toolkit. However, the Kubernetes infrastructure and MQTT message bus approach is hardware agnostic and can easily incorporate both cloud and edge compute to fit the specific needs of a range of QSR workloads and business use cases.
Our research in this area is ongoing, and what we have talked through here is just one potential application of a modern architecture and publish-subscribe model. Beyond this publish-subscribe model, a Kubernetes-based approach to standardized modern infrastructure has a wealth of applications across not only Quick Serve Restaurants, but virtually any organization looking to squeeze more ROI out of their infrastructure and harness the power of AI to deliver more impactful customer experiences.
We view Kubernetes and containerization as the future of computing and would love to work with you to see how we can help solve your business problems ahead of the curve, whether you’re coming at this from the brand side, as a solution integrator, or as an independent software vendor. Whoever you are, if you are interested in talking with us about how we might collaborate, please don’t hesitate to reach out!
For any concrete business development inquiries, please do contact Kristen Call, our Senior Industry Advisor for Retail, Banking, and Hospitality. If you’d just like to discuss with any of the authors of this paper, though, here’s how to get in touch:
David Hibler
Notices & Disclaimers
Performance varies by use, configuration, and other factors. Learn more at www.Intel.com/PerformanceIndex
Performance results are based on testing as of dates shown in configurations and may not reflect all publicly available updates. See backup for configuration details. No product or component can be absolutely secure.
Intel technologies may require enabled hardware, software, or service activation.
Your costs and results may vary.
© Intel Corporation. Intel, the Intel logo, and other Intel marks are trademarks of Intel Corporation or its subsidiaries. Other names and brands may be claimed as the property of others.
