Requirements

Functional Requirements:

• Log workouts
• View history & basic stats.
• Sync across devices.

Non-Functional Requirements:

• Low latency
• High availability
• High scalability

Use Cases:

1. User should be able to pair/unpair fitness devices to the application
2. User should be able to add/edit his personal details to the application (weight, health history, height)
3. User should be able to log his workout into the application from his fitness devices. No need of live streaming of data to the application. Device can share the details once the workout session is marked as complete
4. Types of devices:
   1. devices which directly connect to internet and share data to the portal
5. User should be able to view history, graphs and related analytics on the application
6. User should be able to pair/unpair fitness devices

API Design

1. User details API: API to add/edit user details (age, height, weight) and devices (remove devices) to the user profile
2. View workout API: API to view the workout details including time series graphs. Rendering of graphs is handled by front end logic and libraries
3. PayloadAPI: API to extract workout metrics and add them to the queuing system

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

1. App Gateway: First Level of interface for the users. Looks at the user request path and routes the request to relevant backend service. Handles authentication, throttling and acts as firewall. Authentication is through device tokens issued to the fitness devices during registration. Makes use of external 3rd party providers for authentication and authorization

path: RootURL/v1/userdetails . Gateway routes the request to user details service

path:RootURL/v1/viewworkout . Gateway routes the request to view worktout service

path:RootURL/v1/logworkout . Gateway routes the request to log workout service

1. Queuing system: Queuing broker to send workout details to log work out service asynchronously. The user fitness device will transmit the workout log and details to the log work out service using this broker. Usually configured on middleware services like mulesoft, CPI etc., Usually a cloud SaaS service to autoscale. User request is authenticated on a third party authentication service.
2. User details service: Stateless service hosted behind a load balancer and auto scaler. This service adds/edits user details (height, weight, age, devices) to the user profile. This service gets the user details in REST API format from user
3. Log workout service: Stateless service hosted behind a load balancer and auto scaler. This service adds work out log to the database. This service gets the workout log in the Queuing system
4. View workout service: Stateless service hosted behind a load balancer and auto scaler. This service will show the workout numbers to the client devices. The client devices will render the numbers into necessary graphs and display to the user
5. Payload API Service: This is a stateless service hosted with autoscaling as it is light weight. This will extract the payload related to workout metrics sent the device through the API gateway in the REST API format and add it to the queue.
6. Database: A postgreSQL database usually hosted on a cloud with a PaaS agreement. Table structure is as per the ER diagram.

1. 1. Consistency: Eventual for all the data types except passwords
   2. Replica: Read only replica with eventual consistency
   3. Indexing: Indexed based on the userid in the workout sessions table and based on workout session id based in the workout metrics table
   4. Partitioning: No need to partition at an initial stage. Later we can explore partitioning based on month or a quarter for faster retrieval of the data
   5. Connection manager (ex: db pool) implemented for faster connections for the backend services with the DB

Addressing offline Duplication:

Each workout message generated by the device has a unique id, this id is a combination of UUID of the device and the workout start date and time. Every time a device uploads workout details to the queuing system, the device will note the id of the last added workout session. Next time, when the device is online, it will check the last added workout id and uploads the workout session details which are after the last added workout session. This will ensure that the device functions well even if it is offline for certain periods without missing any workout sessions

Detailed Component Design

a) Database: Considering 1 lakh customers doing 30 min workout on an average with 5%annual growth rate, we will need around 1TB of storage for each primary and replica databases. In azure, we will use General Purpose 8 vCore

32 GB RAM, 1 TB Premium SSD as the DB storage

b) Backend end services (including payload api service): The log workout service, view workout service and user details services are hosted as microservices in their own container. For 1 lakh customers doing 30 min workout on average, each container needs 1 CPU and 1 GB ram to start with. In order to manage for flexibility and reliability, we will start with 2 containers for each backend service being a load balancer and auto scaler. As of now, the estimated requests per second during the peak hour is 4 per second. Auto scaling rule is to scale when requests >50 per second. Additionally, when CPU consumption is >70% scale out and scale in when CPU consumption is <30%. THe log workout service will also scale in and out based on queue length (i.e scale out when >1000 messages waiting in the queue)

c) API gateway: Azure API gateway with consumption tier supporting autoscaling.

d) Secrets Manager: Database secrets and queue secrets are maintained in the secrets manager. Secrets manager will authenticate the requests coming from backend services using RBAC and recieve credentials for interacting with Datbase

e) Queuing system: Queueing system. High available and auto scalable system available on cloud like AWS or Azure or enterprise middleware

f) Authentication Service: Third party authentication service available as SaaS or Microsoft Azure IAM

f) Authentication and authorization architecture:

• Client device to app gateway authentication is through mTLS using authentication service provider like entra ID
• App gateway to payload API authentication is through mTLS or Oauth2.0 token using authentication service provider
• Payload API to queuing system authentication is through IAM and RBAC using external service provider with signatured messages
• Queuing system to Log workout service authentication is through IAM and RBAC using external service provider with signatured messages
• App gateway to user details service or view workout service authentication is through mTLS or Oauth2.0 token using authentication service provider
• User details/View workout/Log workout service to database authentication is through IAM and RBAC at external service provider. User details will have read/write ; View workout will have only read; Log workout will have read and write permissions
• User details/View workout/Log workout service to secrets manager authentication is through IAM and RBAC at external service provider

g) Network architecture:

API gateway will have a public IP. Remaining services will have a private IP.

• Subnet 1: App gateway with rules to allow public IP traffic and outbound traffic to authentication servers and subnet 2.
• Subnet 2: Load balancing services to allow traffic from app gateway and outbound traffic to subnet 3. Firewall and DDOS configured on API Gateway
• Subnet 3: Payload API, log workout service, user details service and view workout service api with rules to allow traffic only from load balancers and outbound traffic to databases, secrets manager and authentication servers
• Subnet 4: Secrets manager and Databases to allow traffic only from subnet 3 and outbound traffic to authentication servers and subnet 3.
• Subnet 5: authentication servers to accept traffic from subnet 4, subnet 3 and subnet 1.