Loading...
Assumption here is that users will be inputting their data manually into the application to record their diet, physical activity and other relevant metrics.
Scalability
Fitness apps should be usable by anyone and anywhere with data being tracked and passed to our hub via the internet when connection is available. As such, it will require horizontal scaling in order to accommodate for a growing user base across a variety of nationalities.
As such, we can assume the daily users of our application to be anywhere between 50 - 100 million
Security
Tied to usage over multiple nationalities specifically it is critical that the application adhere to various data tracking laws as pertaining to the region in which the application may be deployed. For example rules for data will be different between NA and EU due to GDPR, and these will need to be accounted for. In addition it is important to introduce encrypted channels by which our data will flow in order to prevent malicious actors from hijacking/stealing data pertaining to our users health which is traditionally considered to be private information.
Availability
Our data should be readily available for users to query especially when reviewing details such as goals or historical metrics pertaining to a given user.
Possible Error cases to consider:
As mentioned in the previous segment, the expected number of daily users for this application can be between 50 - 100 million users.
The number of requests that we will handle per second however will include various events such as goal setting, physical activity reports, user registrations, requests for historical data, updates to specific goals for progress or shifting goalposts and etc.
As such it can be estimated that on average we can see about 20 million requests per second.
The incoming requests sizes will typically be on the smaller side, involving common features such as the user_id, goal_id, and date range which would sum up to be roughly 50 bytes per request for the largest sects.
This means that on average amount of incoming data per second will be 10 MBs per second.
On the API side of things, leveraging something like websockets is an option, but is not entirely required as small sects of data like current goals can be tracked on a user's device and leveraged to generate notifications directly as opposed to increasing traffic on our end for such matters. As such, using REST APIs is perfectly serviceable for our needs. The following calls will be leveraged:
register_user(username, password(hashed), date_of_creation, device_type (this is for special cases like betas and such in the future)
set_fitness_goal(user_id, activity_type, interval_frequency, intensity, duration, notify)
set_dietary_goal(user_id, dietGoalJSON (this can contain information about a variety of things like frquency of meals, intake of nutrients, time range and so on)
start_workout(user_id, exercise_type, start_time) -> Returns some id that will be used to mark the end of a session
end_workout(session_id, end_time)
update_workout_goal(goal_id, fitnessGoalJSON)
update_dietary_goal(goal_id, dietGoalJSON)
progress_dietary_goal(goal_id
send_workout_progress(sessionId, statsJSON)
get_historical_workout_data (user_id, start_date, end_date, workout_type(optional)
get_historical_dietary_data(user_id, start_date, end_date, data_type(optional))
Consistency is a little less of a concern here since network failures and other error states can result in situations where data is not correctly reported by a user for some period of time until manually corrected or error state is resolved. As such availability of said data for quick reads is critical. In addition to this, due to the high volume and variety of data we are receiving it will likely be good to introduce some layer of partition tolerance that will be malleable for an incoming surge of consumers who may be using our product.
As such MongoDB would be a good option in order to split our data into various Documents that can quickly be read from.
The following Documents will be leveraged:
User Document:
Physical Fitness Goal Document
Dietary Goal Document
Fitness Session Summary Document
Fitness Session Log Document
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...
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...
Explain any trade offs you have made and why you made certain tech choices...
Try to discuss as many failure scenarios/bottlenecks as possible.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?