System requirements

Functional:

1) User can check and track the physical activities like gym exercise, dancing, cardio, cross fit exercise and meditation.

2) User can set goals for all the activities.

3) Goals:->

• increase in number of reps and sets for any exercise
• increase and decrease in time duration for any exercise.
• Increase in weight after some time later
• Increase in time for any activities.
• Reduce in weight or increase in weight
• Muscle improvement for any body part

4) User can monitor their activities like:->

• Weekly/Monthly report for activities.
• Number of reps and sets for any exercise.
• Number of steps.
• Heart beat and pulse rate can also be monitor

Non-Functional:

1) Availability :-> App Server should be available in any case weather it has internet connection or not.

• Do horizontal scaling for the server with rate limiting capabilities.

2) Consistency:-> User can see regular updates for their activities. Activities can be update with latest information

• We can use any sql or nosql data for this. But we can use mysql for sql and mongodb database in the nosql, because we can consistent database. It is highly consistent database.
• We can use mongodb as time series database also for monitoring the activities using huge amount of data can be stored as requirement grows.

3) Authentication vs Authorization:-> Register user only see their own data in the system.

4) In-memory interactive dashboards for live updates, trends, events and alerts

5) Ability to handle multiple logins, multiple queries and high load.

.

Capacity estimation

1 billion users

time -> 8 bytes

request metadata -> 90 byte

100 byte in single request

Average user active at same time:-> 30% -> 30 Million

Peak used active at same time:-> 60 % -> 60 Million

Number of request user can make to APP server-> 10 Req/sec

Let's take average user active per day

30 Million * 10 * 60 * 60 * 24

30 Million * 10^5

3000 Billion * 100 byte = 300 TB per day

API design

Server API's

GET /api/fitness/tracking/getActivities/{activity}/{user_id}

POST /api/fitness/tracking/AddActivity

POST /api/fitness/tracking/AddGoals

GET /api/fitness/tracking/getGoals/{activity}/{user_id}

App API's

GET /api/fitness/monitoring/sendUpdates --> in time-series data, server will fetch data using server polling like prometheus

Database design

User Table

id, Name, Address, Location, Mobile_Number, Email, UserType

Activity

id, Name, Activity_Type

Exercise

id, Name, Activity_id

Goal

id, Name, Exercise_Id, Maximum_Reps, Maximum_Weight, Number of Laps, Maximum_Duration

High-level design

Request flows

CRUD for activities and goals

App Client -> Server -> Cache -> Database

CRUD for monitoring the progress of all the activities and goals

APP Client <- Server -> Cache -> Database

Detailed component design

Trade offs/Tech choices

For consistency:-> We have choose mongodb nosql database for scalability and high performance database.

We can choose other timeseries database like infuxdb and TSDB, it is extension of postgres relational database with time series functionality. But ingestion speed is less compare to mongodb.

Failure scenarios/bottlenecks

Database should scaled and available for getting and storing the data to avoid single point of failure of DB.

App also should be available with the help of horizontal scaling.

At high load, it will sustain with peak load, it wouldn't go down with memory leak and CPU utilisation.

Future improvements

Suggestion as per exercise and also nearby park and gym

Live coaching in the APP