Creating a kiosk application capable of scaling from a handful of kiosks at a single location, up to thousands of kiosks spread across multiple regions requires that you design for scalability from day one. As a kiosk application developer, I’ve witnessed too many startup companies become so focused on getting to market in the shortest possible timeframe that they completely neglect designing for scalability. As their customer base grows they begin deploying kiosks at multiple locations and their server load increases. Then they’re surprised to find out that their kiosks don’t perform well on a larger scale. This is because a scalable design doesn’t happen by accident, it requires careful planning and a time investment upfront or else you’ll end up needing a major overhaul of your kiosk application as your customer base grows.
My goal for this article is to help you design your kiosk applications to be capable of handling massive growth by outlining the major principles of a scalable kiosk application.
1. Offload computation to the kiosk to reduce the workload on the server
For scalability, I would recommend trying to offload as much computation to the kiosk as possible. This can also include client-side caching, user input validation, or any computations that can be performed on the kiosk to avoid processing on the server.
Today, less applications rely on server generate HTML but opt to invoke micro services on the kiosk. By doing all your HTML manipulations on the kiosk and only asking the server to return data, it takes a huge amount of processing off of the server. This frees up additional bandwidth and resources on the server allowing you to scale for a larger kiosk deployment while minimizing server expenses.
2. Choose the right database engine based on the nature of your data
The use of the correct database engine for the job is critical for scalability. A lot of times SQL Server is the right choice. Other times an alternative NoSQL database engine like MongoDB may be better suited to the nature of your data and will result in better performance at any scale. By using a persistence layer you can separate business rules and user interface from the data model which makes it easier to migrate between database engines.
You can also increase database performance through the use of hybrid, in-memory database mechanisms. Most modern database engines now have the ability to move commonly utilized tables and database objects into memory for fast accessibility while also maintaining persistence integrity and transactions. Microsoft’s Hekaton is a good example of this hybrid in-memory database technology. The use of hybrid in-memory database mechanisms can increase database performance 50 fold.
3. Use a reliable content delivery network with geo-location to rapidly deliver content
If your kiosks are distributed over long distances it’s important to use a reliable content delivery network (CDN) capable of guaranteeing reliable uptime and data storage geo-location. CDN’s like Microsoft Azure will detect where your kiosk is located and will automatically cause it to pull resources from the nearest Azure server. Geo-location services can ensure optimal performance by distributing your data across multiple servers and always using the server nearest to your kiosk.
4. Ensure maintainability through modular design and loosely coupled layers
In order to ensure maintainability as your kiosk project scales it’s important to break the application into modular components that work together, but can be tested independently.
These components typically include:
- Data Storage:
- Simple storage of data in organized and normalized structures
- This storage should be interchangeable with another type depending on needs such as moving from MySQL to SQL Server or MongoDB
- Persistence Layer:
- This is the layer that talks between the User Interface and the Data Storage
- Rules in this layer should be limited to data integrity
- Business Rule Layer:
- Talks with the Persistence Layer (not directly to Data Storage) this way Data Storage can operate independently
- Handles complex and simple calculations
- Handles Application Rules not to be confused with data integrity rules in the Persistence Layer
- User Interface:
- Talks with the Business Rule Layer
- Handles users inputs by communicating with Business Rule Layer
- Handles outputs by communicating with the Business Rule Layer
Consider creating kiosk projects as smaller parts that do specific duties (DLLs), this makes each unit interchangeable as well as highly testable. The independent nature of each of these components also reduces risk when modifying code in one section of the application as well as make the application easier to manage in a Team environment where multiple developers may be working on the same application.
It’s also important to loosely couple layers either through interfaces, services, dependency injection, etc… Loosely coupled layers make it much easier to make modifications or enhancements later on or even swap out entire database engines. For example, switching from SQL to MongoDB would require ZERO code modifications with dependency injection implemented, just a new DLL.
5. Regularly analyze your code to ensure it’s running efficiently
In order for your kiosk application to scale properly, it’s important that your code run efficiently – which can be accomplished through the use performance profilers like those created by Red Gate. When you have just a few kiosks deployed, inefficiencies in your code might be unnoticeable. The larger the deployment grows, however, the more noticeably poor code affects the experience. I’ve know people that work at Yahoo and Yelp that will spend WEEKS trying to get their algorithms even just a few milliseconds faster because those saved milliseconds add up for their large operations.
Conclusion
I hope that by reading this article you’ll begin to think big and well into the future when it comes to deploying your kiosks. I want you to think beyond deploying that first pilot kiosk, but instead visualize how you’ll deploy thousands of kiosks across the globe. This is the goal, for most of us anyways, to see how many kiosks we can sell and how many customers we can serve. Scalability requires careful planning upfront, but if you follow the design principles outlined in this article you’ll be ready for massive growth in the future.
If you’d like more information on developing scalable kiosk applications please check out my series Getting Started Developing Kiosk Software.
- Avoid These 12 Mistakes Companies Make on Their First Payment Kiosk - April 6, 2019
- 6 Tips for Boosting Customer Engagement at Your Kiosks - March 23, 2019
- How to Create a Customer Survey Kiosk - November 8, 2017