Scalable Back-End for an AI-Based Diabetes Prediction Application

TL;DR

This paper addresses the challenge of building a scalable back-end for an AI-based diabetes prediction app to support large user populations while maintaining performance and reliability. It adopts a horizontally scaled microservices architecture with sharded PostgreSQL, Redis caching, and RabbitMQ-based asynchronous inference to handle long-running predictions and XAI explanations. The evaluation shows that 83% of features meet the defined targets at 10,000 concurrent users, validating the architecture's scalability and reliability for health-tech use cases. The work highlights practical trade-offs between immediacy and stability when offloading heavy ML tasks and outlines directions for enhanced security and monitoring.

Abstract

The rising global prevalence of diabetes necessitates early detection to prevent severe complications. While AI-powered prediction applications offer a promising solution, they require a responsive and scalable back-end architecture to serve a large user base effectively. This paper details the development and evaluation of a scalable back-end system designed for a mobile diabetes prediction application. The primary objective was to maintain a failure rate below 5% and an average latency of under 1000 ms. The architecture leverages horizontal scaling, database sharding, and asynchronous communication via a message queue. Performance evaluation showed that 83% of the system's features (20 out of 24) met the specified performance targets. Key functionalities such as user profile management, activity tracking, and read-intensive prediction operations successfully achieved the desired performance. The system demonstrated the ability to handle up to 10,000 concurrent users without issues, validating its scalability. The implementation of asynchronous communication using RabbitMQ proved crucial in minimizing the error rate for computationally intensive prediction requests, ensuring system reliability by queuing requests and preventing data loss under heavy load.

Figures (7)

• Figure 1: Architecture of Solution 1
• Figure 2: Architecture of Solution 2
• Figure 3: Final System Architecture Overview.
• Figure 4: Entity Relationship Diagram (ERD) of the Application.
• Figure 5: RPS vs Virtual Users for Get Activity Endpoint.