This is a guest blog post by Dante Monaldo, co-founder and CTO of Pluto Money

Pluto Money, a San Francisco-based startup, is a free money management app that combines banking, behavioral economics, and machine learning (ML) to guide Generation Z towards their financial goals in college and beyond. We’re building the first mobile bank designed to serve the financial needs of Gen Z college students and grow with them beyond graduation.

The importance of establishing healthy financial habits early on is something that I and my co-founders Tim Yu and Susie Kim deeply believe in, having founded Pluto based on our own experiences. We apply financial rigor to our business in the same way. Using the cloud was a natural choice for us, as cloud services have lowered costs and brought flexibility previously unimaginable to rapidly growing companies.

We chose to use AWS as our primary cloud platform, from core compute to ML, because the AWS solutions are robust and work seamlessly together. Our team is growing, and—as is the case with many startups—we all wear many hats. As such, we rely on the AWS offerings to save us time while giving us an enterprise-grade tech stack to build on as we scale our team.

The heart of Pluto Money is our client API, which serves all requests originating from the Pluto Money mobile app. Written in Node.js, it runs on Amazon Elastic Compute Cloud (EC2) instances behind a Classic Load Balancer. This was architected before AWS released the Network Load Balancer and Application Load Balancer options. However, the Classic Load Balancer serves the same purpose for us as an Application Load Balancer, and we will likely migrate to it in the near future. The instances scale based on a combination of CPU utilization and the number of concurrent requests.

All persistent data—such as user accounts, saving goals and financial transactions—is stored in an encrypted MongoDB replica set. To minimize latency, many requests are pulled from a Redis cache that is stored locally on the NodeJS Amazon EC2 instances (because why make a 10 ms MongoDB request when a 1ms cache request will do?). The cache expires and refreshes periodically to protect against stale data.

Some calculation-intensive requests take longer to process and are not as time-sensitive as requests originating from the mobile app, such as communicating with a user’s bank when they have new transactions or re-training models on new financial data. We push these requests into an Amazon Simple Queue Service (SQS) and have a group of AWS Elastic Beanstalk workers chip away at the queue. This prevents any increase in calculation-intensive requests from slowing down the client API.

Of course, we use Amazon SageMaker to train, test, and deploy our ML models. One such model uses anonymized spending data from users that opt-in to compare their finances to similar peers—based on criteria set in their user profiles. For example: Sarah, a 21-year-old college student at UCLA, can see how her spending anonymously compares to other 21-year-old female UCLA students’ spending across different categories and merchants. This comparison provides important context for college students who are trying to better understand their own spending behavior.

Models are trained and tested in Jupyter notebooks on Amazon SageMaker, using both proprietary algorithms and the built-in algorithms that are available. We love that we can train and test ML models at scale the same way any data scientist does locally on their machine. When it comes time to deploy a model, that same data scientist can create an endpoint and provide the request and response parameters to an engineer on the team. This handoff is much more efficient than having the engineer go back and forth with the data scientist trying to understand the intricacies of the model. When revisions are needed, we point the requests (originating from the group of EC2 instances mentioned before) to the new endpoint. This allows us to have multiple endpoints live for testing in different sandbox and development environments. Moreover, when the model is revised, the engineer doesn’t need to know that anything changed, so long as the request and response parameters stayed the same. This workflow has allowed Pluto Money to iterate quickly with new datasets, an important requirement for building accurate ML models.

Since Pluto Money’s public beta launch in late 2017, we have helped tens of thousands of students across more than 1,500 college campuses save money and form better financial habits. And we are excited to continue to scale our technology with the support of AWS. Gen Z will account for 40% of U.S. consumer spending by 2020. We at Pluto Money are building the bank of the future for Gen Z—one that is radically aligned with their financial wellness more than anything else.