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.
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...
One of the biggest trade offs made in the situations was the leverage of Mongo DB in place of a traditional RDBMS system.
The reason Mongo was used was due to its high availability and tolerance to partition. Given the daily logs for an given consumer can consists of thousands of session logs alone, that memory consumption can wind up adding up and resulting in traditional RDBMS systems in requiring more and more frequent partitions throughout its lifetime. In place of that MongoDB can easily distribute data amongst its various redundant copies and remain easily accessible despite this.
This however comes at the cost of consistency. While MongoDB is an eventually consistent DB type, the fact remains the each event coming in will not be immediately ready for reading which means there is a required buffer period when looking up historical data, and outside of session data logged on ones device, overall historic data will not be visible up until the present until the buffer period has been accounted for.
Try to discuss as many failure scenarios/bottlenecks as possible.
The first major failure scenario involves a lack of network connectivity for the device that may currently be tracking an ongoing session. This sort of scenario tends to happen particularly during hikes and the like meaning that the intermediary data and events would need to be logged in a queue within the device that can hold them for some period of time before sending them out for processing once network connectivity is regained.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?
There is room currently within the application in order to leverage Machine Learning Models which can then provide users with personalized suggestions in regard to goal setting, possible outliers in historical data, and other such analytical information in regard to the user's health. ML can also be used to quickly enter data regarding dietary goals set by users as well. For example, if a user were to scan an ingredients/nutritional information list of foods they consume in a given meal, that information can be quickly uploaded into a form that can quickly be reviewed before sending progress updates.
Implementation of third party devices like Apple Watches and like can also be done in order to reduce manual entry of progress and such. In these situations the apple watch itself would act as a client and set out signals and logs pertaining to session workouts instead of having the user themselves have to manually enter some data.