Why AWS

We've chosen AWS over other cloud providers due to its wide range of services. The scalability and flexibility of AWS would allow us to easily adjust resources based on demand, ensuring optimal performance and cost efficiency. AWS would also enable us to deploy applications closer to targeted regions, reducing latency. We also wanted to use AWS's robust security features, including firewalls, encryption, and identity management. Some of the main reasons for choosing AWS are:

AWS Lambda,

• Allowed us to run code without managing any infrastructure, which made it the ideal candidate for building serverless architecture. The Lambda service would reduce management overhead, allowing our engineering team to focus on development tasks instead of infrastructure.

• Lambda automatically scales to handle incoming requests running our code across multiple Availability Zones for high availability and fault tolerance.

• We needed a cost-effective solution, and Lambda costs are associated with code execution time, which made it ideal for our needs.

• Can be used to build event-driven architectures that integrate with other AWS services, such as Amazon S3. Consideration was made for possible future-related features.

Amazon OpenSearch

The application’s static content is hosted on a third-party headless managed CMS service. This introduced speed and performance issues when retrieving content via the CMS API. This was due to the content's complex and nested data structure, and the lack of the CMS’s ability to serve the entire data model, including nested children. So we needed to find a fast and efficient way to deliver content to the application’s users. Open Search was considered for the following reasons:

• OpenSearch would be able to handle large amounts of data and scale automatically to meet our needs.

• Using OpenSearch as a cache layer between the app and CMS would significantly improve the performance and data access speeds by switching to OpenSearch, as it’s optimized for search and performs faster and more efficiently than retrieving data directly from the CMS API.

• Automatically replicates data across multiple nodes to ensure data availability and durability.

• The service provides network isolation and encryption options to help ensure your data is secure at rest and in transit.

• The client would be charged based on the amount of data stored and the number of requests made by the mobile app, which would help control costs and scale usage as needed.

Amazon RDS

• We opted for a PostgreSQL database and needed a way to host it. Amazon RDS for PostgreSQL made the most sense at the time as we needed a managed database service that would scale up or down based on the business’s needs while providing features such as automatic backups, replication, and failover capabilities.

• The automatic failover capabilities help ensure the database stays available during a primary instance failure.

• RDS supports database encryption at rest and in transit and would also help secure the application’s database using IAM and network isolation. Blocking all outside access outside of a bastion host.

• The service provides flexible pricing options that allow us to pay for additional resources as needed, helping our client save on database costs.

• Can be integrated with other AWS services, such as AWS Lambda or Amazon CloudWatch, to automate management tasks and monitor performance.

AWS API Gateway

• We need to build APIs on AWS. API Gateway seamlessly with Lambda functions, allowing us to create highly scalable and flexible API architectures.

• The service provides various features, such as request validation, authentication, and throttling, that help secure and control access to our APIs.

• We use Cognito for identity management, and API Gateway validates JSON Web Tokens (JWTs) generated by Cognito. We also have the option of a custom Lambda authorizer to validate tokens from external IDPs if needed.

• Can be used to create and manage API keys, which would be used to control access to APIs that don’t require user tokens.

Amazon Elastic Container Service (ECS)

We used ECS On Fargate for the CMS API to server content from OpenSearch,. ECS was chosen to keep our infrastructure consistent across all regional infrastructures. Content-wise, we are using Lambda to insert content into OpenSearch via CMS webhooks whenever the content is published by editors in the CMS. See the bullet points mentioned above related to OpenSearch for more context.

Why the Customer Chose the Partner

Therabody has selected Tech Holding because of our comprehensive experience in architecting and building highly scalable cloud applications and services and our in-depth knowledge of creating mobile applications for iOS and Android. Therabody devices utilize BLE/Bluetooth technology, and our background in that field was a key deciding factor in selecting our organization for this project. 

Partner Solution

The user activity data is captured from the health provider platforms. Apple Health on iOS, Google Fit for Android, and other health partners. Activity data is collected periodically using the Therabody mobile apps and sent to the server via an API. We used RDS for PostgreSQL to store the collected activity data. We built APIs the mobile apps use to communicate with the backend to retrieve routine user recommendations based on their activities. All the API endpoints are secured with a user token issued by Cognito when a user authenticates with the app. The other health providers are integrated with the Therabody app via webhooks. Recommendations are issued by a custom rules engine that matches routine data with users based on their activities based on proprietary algorithms.

It’s worth noting that the content suggestions made by the recommendation engine are served from OpenSearch. The content is stored in a third-party headless CMS service. The mobile app previously pulled the content directly from the CMS API. We opted for OpenSearch to performatively serve the entire data structure without causing long response times.

Results and Benefits

Tech Holding has created a rules/recommendation engine that incentivizes customers to use the app by making personalized recommendations. As observed through analytics, user engagement increased by around 20% in the short term as users updated their mobile applications to the latest version. User engagement has steadily increased since the app's introduction of personalized recommendations.

Next Steps

We plan to include other third-party health provider service integration in the future and build on the existing framework to create custom user routines. While also exploring the possibility of leveraging the capabilities of other services, such as Amazon Personalize, to improve recommendations. 

About the Partner

Tech Holding is founded around the premise of helping organizations achieve superior technological journeys using modern technology by providing AWS cloud-native services. We help organizations of varying sizes, from early-stage startups to large Fortune 50 companies, through their cloud journey. Our deep technology expertise in cloud transformation, mobile technology, and building scalable platforms is unparalleled. With our team of experienced Solution Architects, Product specialists, and Engineers, we can help you achieve new heights.

APN Programs:

AWS Partner - Advanced Consulting Partner

AWS RDS Delivery Partner

AWS Solution Provider Partner

AWS Tech Stack:

Amazon Cognito, AWS Lambda, API Gateway, Amazon SQS, Amazon RDS, OpenSearch, ECS.

Other Stack:

Terraform/Terragrunt, CircleCi, Fastlane Node.js, Kotlin (Android), Swift/UIKit(iOS), Strava, Google Fit, Apple Health