Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
RedisConf17 - Smartwaiver - Using Redis for Kiosk Registration Command and Control
1. Using Redis for Kiosk Registration
Command and Control
Ted Knudsen - CTO Smartwaiver
2. Smartwaiver - Online Digital Waivers
• Founded in April 2012
• Over 20+ million digital waivers created
• Corporate Headquarters in Bend OR (in Old Mill District)
• Customers all over the world but majority are US based.
• Saturday is always the busiest day of the week for waivers.
3. Background
• Started at Autodesk in 1993 with SAP Enterprise software
• Tealeaf Technology (online user experience) from 2000-2010
• Message Bus (email service) - Cofounder 2010 - 2015
• Smartwaiver (digital waivers) - Dec 2015
• Hobbies: Trail running and climbing
• Favorite Brewery - Crux
4. My Redis History
• My first NoSQL experience started in Dec 2010 with Redis 2.0
• I have used every major release of Redis over the past 7 years in a
production environment
• With Message Bus, Redis was a critical component in the infrastructure
used to send billions of emails
• Current Production version: 3.2.6 with Redis Enterprise self hosted at
AWS
5. Smartwaiver Stack
Cloud – AWS
DB – MySQL on RDS
Caching – Redis Enterprise
Queues – Simple Queue Service (SQS)
Storage – S3
Deployment – Ansible
Languages – PHP (5.6) and Python (Ansible)
6. Waivers at Kiosks
Smartwaiver provides to customers an
app (iOS or Android) to create a kiosk
for signing waivers.
In most cases, the kiosk is an Apple
iPad locked in a case and the users
are directed to sign the waiver before
participating in an event.
We currently have over 4000 active
kiosks creating waivers.
7. Kiosk 2.0 – Command and Control
Goals for Kiosk 2.0
• Auto registration
• Ability to prepopulate a waiver with a participant’s information from a
remote source
We’ll take a look at how we solved these problems with Redis.
8. Kiosk 2.0 – Hack Day
I knew I wanted to have Redis at the heart of the communications between
the kiosks and the control center. But I wasn’t sure exactly how to do it
and decided to dedicate a day to explore the possibilities. It was a
productive Hack Day!
9. Kiosk 2.0 – Kiosk Registration
The registration process was loosely modeled after the process some
SmartTV’s use to link a service to the device.
• The kiosk makes the registration call to the API (/kiosks/xyz-123/register)
• This creates a key which is the registration code and the unique ID of the
device
• Entering the registration code in the kiosk manager on the website then
links the device to the account in the database.
10. Kiosk Registration
This is the high level view of how the
kiosk registration works.
Kiosk 1
Kiosk Manager
Enters: 453212
/kiosks/xyz-1234/register
KEY: 453212
VALUE: xyz-1234
Expires: 300
11. Kiosk Registration
After starting the application on the
iPad the user is prompted with the
following screen. They then press on
the “I Have a Smartwaiver Account”
button to create a registration code.
12. Kiosk Registration
The registration code is presented to
the user which is used in the kiosk
manager screen to link the kiosk to the
account.
In Redis – the registration code is the
key and has a 5 minute expiration
This simple solution requires no
backend “cleanup” for missed
registrations.
And another added benefit is the kiosk
never requires any data input.
13. Kiosk Registration
In the kiosk manager, the user enters
the registration code.
In the backend, the API checks for the
key with the registration code in Redis
and if found it then links the device to
the account in the database with the
device ID.
14. Kiosk 2.0 – Kiosk “Commands” in Redis
The second goal was to create a way to send commands to a kiosk to control
its behavior.
• Each kiosk checks on a timer for a “command”.
• A “command” is just a hash key with an expiration of 5 minutes. The key
is the device ID of the kiosk.
• The hash contains the action and JSON data payload.
15. Kiosk 2.0 – Pre-Populating a Waiver
The first command we have implemented is to pre-populate a waiver with
participant information.
Pre-populating a waiver with a participant’s information speeds up the
process of completing a waiver. Making the process as easy as possible is a
goal for Smartwaiver.
16. Kiosk Control
This is the high level view of how the
kiosks communicate back to Redis for
a command.
Load Balancer – ELB
API Server – EC2 Instance
Redis
Enterprise
Kiosk 1
Action: autofill
Payload: JSON
Kiosk 2 Kiosk 3
Kiosks check for a
command
Load Balancer
API Server
17. Kiosk Control
To make it easy to send participant
information to a kiosk we created a
Chrome Extension that can be used to
enter the information from just about
any source (online CRM, registration
form, etc) with some simple
copy/paste operations.
18. Kiosk Control
The extension shows which kiosk is
available for receiving a command.
Kiosk availability is determined via
data from Redis. Each kiosk updates
its status (when online) via the API on
a regular basis.
19. Kiosk Control
After confirming the data the
information is stored in Redis as a
command with the data from the
participant.
The kiosk from Step 3 will read the
command and start the waiver process
for that participant.
21. Smartwaiver and Redis
Of the 4000 active Kiosks, over 2000 have now
updated to the new version 2.0
We will be releasing the Chrome extension in
June and we will see what the adoption rate is
over the summer (which is the busiest time of
the year for us).
I always use Redis in my development tool kit
and while there are always many ways to solve
a problem I have found that using Redis is
usually the cleanest and easiest.