Spendgo is a San Francisco-based technology startup innovating customer loyalty at the point-of-sale (POS). If you’ve bought a Razzmatazz or Caribbean Passion smoothie recently, you’ve probably already interacted with Spendgo. As Jamba Juice’s preferred national loyalty provider, Spendgo powers over 1.5 million Jamba Juice Insider Rewards members. They are installed in over 650 Jamba Juice stores and handle between 6 to 10 customer transactions per second.
Apart from the consumer-facing touchscreen that customers engage with, the other piece of hardware that Spendgo has patented is called a Transaction Link™. This is a small Linux appliance device that sits between a POS terminal and the printer, and captures receipts without any software installation required by the merchant.
For the merchant, Spendgo provides a touchpoint to introduce personalized offers rebate options during transactions, capture customer mobile numbers in a non-intrusive manner, and enhance customer interactions and incentivize repeat purchases. The Spendgo platform can also push messages to the touchscreens, mobile devices and POS receipt printers—which creates opportunities to remind customers of upcoming reward moments (“Only 10 points until your next reward!”) as well as notify them about special offers (“Get $3 off your next purchase by fully activating your Jamba Insider Rewards account!”).
Spendgo’s challenge was getting organized data from fragmented POS technologies and scale an infrastructure that could handle millions of real-time interactions during peak consumer spending. They were able to resolve the POS fragmentation issue using their Transaction Link to capture transaction data from the print feed, but now found themselves needing a way to scale its massive data volumes.
In 2013, Prasad Mokkapati joined Spendgo as an architect, at an early time in Spendgo’s growth, when the company was evaluating its Spring / Tomcat / Hibernate and the JSP model. Mokkapati saw some limitations to that stack’s ability to scale the business as Spendgo began to sign more national accounts and had the task to scale its devices to support millions of customers.
“We realized we really needed to scale this thing up, and that wasn’t going to happen with synchronous calls and blocking calls,” said Mokkapati. “Depending on the complexity of transaction data, the processing could take some time, and you can’t block the user at the point-of-sale. So that wasn’t a good model. The strong need to move to asynchronous was really what led us to take a closer look at Akka, Play and Slick.”
Today Spendgo powers its thousands of POS terminals through Scala, Akka, Slick and the Play framework - a move that Mokkapati says has really helped the company in its explosive early growth days. He cites the following benefits:
Akka Simplifies Message Passing and Failure Handling: “Akka makes it easier for us to separate out the UI from the back end,” said Mokkapati. “A store may have multiple POS terminals, and if a printer goes down, the receipt may be routed to a different printer. Akka allows us to associate the receipts and UI messages coming from different devices easily. We have a merchant actor, a store actor, and device actors - that make it much easier to pass messages and react to events between merchants, stores, and the Spendgo servers.”
More Scalable Codebase: “The complexity of doing this thing with Spring and Hibernate was too great,” said Mokkapati. “We love programming in Scala. In general, the fewer lines of code you write, the easier it is to maintain. It’s just easier to reason with Scala code.”
Strong Type Safety: “Java has type safety, but Java doesn’t have the immutable data types that Scala has,” said Mokkapati. “You have to deal with multithreading in Java, which is very challenging to manage. If you’re dealing with multithreading and immutable data types, you don’t know who is changing what and you end up with a lot of problems. Those problems went away when we switched to Scala.”
The Power of Slick: “If you end up writing queries using lifted embedding the data types with Slick, you can catch changes at compile time, as opposed to writing your own,” said Mokkapati. “This is a huge advantage for constantly changing schemas.”
Play Made Getting on Board With “Reactive” Easy: “Play provided the async mechanism and coupled with Akka allowed us to model these things much better,” said Mokkapati. “Play Framework has some of the best documentation that I’ve seen - it’s very easy for people to get on board.”
Inspired by this story? Contact us to learn more about what Lightbend can do for your organization.