Blog

5 tips for creating massively scalable kiosk applications

Scalable design doesn't happen by accident -- it requires careful planning and an upfront time investment.

January 7, 2015 by Andrew Savala — CEO, KioskSimple

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, leading to poor kiosk performance. Then they're surprised to find out that their kiosks don't perform well on a larger scale.

Scalable design doesn't happen by accident. It requires careful planning and a time investment upfront. Otherwise, you'll risk a major overhaul of the kiosk application as your customer base grows.

The following five tips address major principles of scalable kiosk applications – all geared toward helping you to accommodate the kind of massive growth that most of us are seeking.

1. Offload computation to the kiosk to reduce the workload on the server.

For scalability, I 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, fewer applications rely on server-generated HTML, opting instead to invoke micro services on the kiosk. By performing all HTML manipulations on the kiosk and only asking the server to return data, a huge amount of processing is taken off the server. This frees up additional bandwidth and resources on the server, allowing you to scalefor 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. Often, SQL Server is the right choice; other times, an alternative NoSQL database engine such as MongoDB might be better suited to the nature of the 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 capable of guaranteeing reliable uptime and data storage geo-location. CDNs 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 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) so that data storage can operate independently. Handles complex and simple calculations. Also 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. Also handles outputs by communicating with the business rule layer.

Consider creating kiosk projects as smaller parts that perform 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 making the application easier to manage in a team environment where multiple developers might be working on the same application.

It's also important to loosely couple layers, 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 wouldn't require code modifications with dependency injection implemented, only a new DLL.

5. Regularly analyze your code to ensure it's running efficiently.

In order for a kiosk application to scale properly, it's important that your code run efficiently, which can be accomplished through the use of performance profilers like those created by Red Gate. When you have just a few kiosks deployed, inefficiencies in the code might go unnoticed. The larger the deployment grows, however, the more noticeably poor code affects the experience. I’ve known 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.

Visualizing your kiosk future

I hope that by reading this article you'll begin to think well into the future when it comes to deploying your kiosks. I want you to think beyond deploying that first pilot kiosk – instead, visualize how you'll deploy thousands of kiosks across the globe. Scalability requires careful planning upfront, and if you follow the design principles I've outlined here 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.

About Andrew Savala

Andrew Savala is the COO of BIxby, with a background in designing and deploying payment kiosk systems. He offers consulting services to companies looking to develop their payment kiosks.

Connect with Andrew: