System requirements

Functional:

1. The user should be able to register the app.
2. The user should be able to add initial data such as height, weight to calculate BMI.
3. The application should display fitness component such as heart rate, daily steps and the number of calories burned.
4. User should be able to set goals, goals can be daily goals and weekly goals.

Non-Functional:

1. The system should be reliable and fault tolerant.
2. The system should be highly available to the user.
3. The system can be eventually consistent, immediate updates of stats may not be a necessary requirement.
4. The system should be secure enough to protect user's data.
5. Latency for interacting with the system should be minimal, for example APIs for setting goals and user registration should not take a lot of time.

Capacity estimation

1. Total user base for the system can be 100 million.
2. Daily active users can be taken as 40 million.
3. The number of servers required for our application can be 40 million / 64000 considering we have a 64 core CPU machine, which will come out to be 625, which is the number of servers we need. Here I have taken 40 million as the peak load for a certain time interval during the day hence 40 million requests per second.
4. Storage estimation - there will be user metadata which will be stored, assuming the metadata for each user takes about 10 KB of space hence we will require 10 KB * 100 million of space in the database, for which we can use postgres.
5. We can have a reporting mechanism for providing users reports of their progress on a weekly basis, these reports can be generated and uploaded to S3, assuming each report takes 100 KB of storage, we will require 100 KB * 100 million of storage for S3.

API design

1. we will have an API for registering user into the system, which we will call as the register-user API, the API will take details such as username, phone number, emailId, height, weight.
2. Another API will be for setting fitness goals which will be the register-goal API, this API would take the fitness parameter such as steps and an integer indicating the number of steps desired.
3. Another API would be to fetch fitness data, fetch/{fitness-parameter}, here fitness-parameter can be steps/calories burnt/heart rate.
4. Another API would be to check progress against the desired goal set by user, monitor-progress/{fitness-component}.

Database design

1. We can use Postgres as a database for user specific details such as user name, emailId, phone number and height and weight.
2. We can have a user table for storing the basic user details and a user-fitness table which can store the inputs such as height and weight of the user.
3. The postgres servers can be replicated to avoid a single point of failure and ensure high availability.
4. the user-fitness table would contain all the computed data such as steps taken, calories burnt and heart rate of the user.
5. The user table can be indexed on the user_id which will be a unique column for every row and this user_id will also be the primary key and will be referenced as a foreign key for the user-fitness table.
6. Since we will be having users from all across the globe we can also have a country column in the user table and the user table can be partitioned on the country basis to enhance query performance.

High-level design

1. Client makes a request which is first handled at the API gateway which takes care of rate limitng and user authentication.
2. API gateway identified the type of request and sends it to the particular load balancer.
3. Load balancer will redirect the request to the particular server by taking into consideration the amount of requests being handled by the servers currently.

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?