System requirements

Functional:

• Active Tracking
  • Log physical activities
  • Log should be based on stored metrics like distance duration and calories burned
• Goal Setting
  • Track user's goals like target steps or weight loss progress
• User Engagement
  • This will remind the user to input workout and not miss tracking physical activities

Non-Functional:

• cost could be a limiting factor
• Only available in the US
• Availability over consistency
  • Data can be eventual consistency
  • More important that the app is available then if the data is stale for short period
• Security
• Simple

Capacity estimation

• 10,000 users in the first year
• assume 20% growth rate month over month
• Assume 20% of current users are daily users (2,000)
• Active logging
  • 2 times per day
• Goal setting
  • 1 time per day
• Total operations per user per day
  • Active Logging (2) + Goal Setting(1) = 3
• Total Daily operations
  • 3 * 2,000 = 6,000 requests per day
• Memory
  • Active logging
    • Assume 1kb per log
    • Activity Logs: $2,000 * 2 (loggings) * 1 \text{ KB} = 2,000 \text{ KB}$.
  • Goal setting
    • Assume .5kb per goal tracking
    • Goal Setting: $2,000 * 0.5 \text{ KB} = 1,000 \text{ KB}$.
  • Total daily data: $2,000 + 1,000 = 3,000 \text{ KB}$ or ~3 MB.
• After 1 year 3MB * 365 = 1.1 MB

API design

APIs used by the user:

• Active tracking
  • getPrevious( user_ID, eventType, start_period, end_period)
    • eventType- active, goal
  • createActivity(user_ID, activity, distance calories ,date)
  • updateActivity(user_ID, activity, distance, calories, date)
  • deleteActivity(user_ID, activity_ID)
• Goal Setting
  • getPrevious(user_ID, eventType, start_period, end_period)
  • createGoal(user_ID, goal_info, date)
  • updateGoal(user_ID, goal_ID, goal_info, date)
  • deleteGoal(user_ID, goal_ID)
• User Engagement
  • getRemind(user_ID, last_active_time, day_of_the_week)
    • will store the last time the user used the app

Database design

It would be better to use a NoSQL database since availability would be more important than consistency and to scale horizontally to help with the 20% increase in users every year. For faster retrieval, we can cache data for the user.

High-level design

• The client will first hit the load balancer
• Load balancer will then redirect to application server
• Application server
  • Checked if cached values
  • if not, it will get data from the database
• Will have eventual consistency due to the use a NoSql database.

Request flows

The user will interact with the user to retrieve data.

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...

One important component is the user engagement component. When the user logs a new activity into the app we will keep track of this time and the day of the week. Most people have daily routines, so it is safe to assume that the user will perform that activity around the same time on that day of the week. We will send a reminder for that time every day to track their activity.

Trade offs/Tech choices

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

The biggest tradeoff here is the database. I chose a NoSql database in order to keep up with the growing active users and to be able to have more availability over consistency.

Failure scenarios/bottlenecks

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

If we have a spike in users, we do have a SPOF with the load balancer.

Something else I can see being an issue is the user trying to update an activity or goal and not seeing it update until a few seconds versus ms which would be done with a SQL database.

Future improvements

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

We could add more load balancers that each have health checks to help combat the SPOF.

Adding more features like a social aspect would be great but would require a lot more RPS. It would be easy to scale horizontally for this feature since we decided to use a NoSQL database.