Requirements

Functional Requirements:

• Log workouts
  • User should be able to select from a list of exercises. If exercise is not available in the predefined list, they should be able to add along with some info about the exercise
  • Adding the exercise should include the weight / body weight, the no. of sets and reps in each set
• View history & basic stats.
  • User should be able to select an exercise and he should be able to see what is the maximum weight with which he did that in the past
  • User should also be able to see the past 10 days workouts ( not calendar days, but only those days where he did a workout )
• Sync across devices.
  • The user will primarily use this from mobile devices. So we should support both mobile phones and tablets
  • The user should also be able to generate reports from desktop using browser

Non-Functional Requirements:

• No. Of Users
  • Let's target around 100k users for the app
• High availability
  • All the personal best data will be kept on device and will be synced up once a day. Hence the application is not required to be always available. The user can even use an offline version without any impact to user experience
  • Having said that, we should aim to be available for 99.9 % of the time
  • Peak hours
    • Morning 6 - 9 and Evening 6 - 9 would be peak hours
    • During this time the load would peak to at least 60k users. Our system should remain available under this load. Even if the app server is down, the mobile app should store the data in its local memory and should try to sync the data with the server once it's available. This will ensure that from the perspective of the user, the system is available for 99.99% of the time.
    • Let's say 10000 users per hour. Each user doing around 3 requests per minute. We are looking at ~100000 requests per hour
  • Responsiveness
    • When the user gets a data or writes a data to DB, the request should finish in 1 ms. Anything more than that will be a visible delay and is unacceptable
• Scalability
  • We are storing the data of a million users. Let's assume that each person will generate around 5 KB per day. For a million users, we would need around 3 TB storage per year
  • We will need to have at least 5 DB nodes with each shard getting replicated on 3 nodes for redundancy.
  • Let's say 10000 users per hour. Each user doing around 3 requests per minute. We are looking at ~100000 requests per hour. We should scale our app servers to ensure that we are able to handle this load. Also, during the non peak hours, we would experience very less load and a single server should be able to handle that. So we need to be able to scale up and scale down the servers
• Security
  • We are dealing with personal information and hence security of that information is of paramount importance
  • We need to secure the data both in transit and at rest
• Consistency
  • Any data uploaded by the user needs to be stored in the DB.
  • There should not be any unintended duplicates
  • There should not be any loss of data.

API Design

1. Get all the exercises
   1. GET : /api/v1/exercises
2. Get all exercises of a particular group
   1. GET : /api/v1/exercises/{category}
      1. category could be the muscle group like chest, deltoids
      2. category could also by other cardio activities like hyrox, running and so on
3. Create new user exercise
   1. POST : /api/v1/exercises
      1. Request body
         1. { exercise_name: <>, category : <>, description: <>, url: <>}
      2. Response -> exercise_id
4. Create new workout
   1. POST /api/v1/users/{user_name}/workouts/{date_with_time}
   2. Request body
      1. { start_time: <> , exercises : List<Exercise>}
      2. Exercise : { exercise_name: <>, sets : LIst<Set> }
      3. Set: { reps : List<Rep> }
      4. Rep : {weight : <>, noOfTimes: <>}
   3. Response
      1. workout_id
5. Create new profile
   1. POST: /api/v1/users/{user_name}
   2. Request body
      1. full name
      2. last name
      3. weight
      4. body fat percentage
      5. height
      6. bmi
      7. date_of_recording
6. Update workout
   1. PUT /api/v1/users/{user_name}/workouts/{workout_id}
   2. Request body
      1. {exercises : List<Exercise>}
7. Delete workout
   1. DELETE : /api/v1/users/{user_name}/workouts/{workout_id}
8. Update user exercise
   1. PUT : /api/v1/user/exercises/{exercise_id}
      1. Request body
         1. { exercise_name: <>, category : <>, description: <>, url: <>}
      2. Response -> exercise_id
9. Delete user exercise
   1. DELETE : /api/v1/user/exercises/{exercise_id}
10. Get workout between date range
    1. GET : / api/v1/users/{user_name}/workouts
       1. Request
          1. start_date:<>
          2. end_date:<>
11. Get vitals between date range
    1. GET : /api/v1/users/{user_name}
       1. Request
          1. start_date:<>
          2. end_date:<>
12. Get basic stats
    1. GET /api/v1/users/{user_name}/current

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

Components involved

1. Mobile app
2. Desktop browser app
3. API gateway
   1. Our services can handle a maximum of 100 requests per second. We will enforce this using a sliding window mechanism that allows only 100 per second
4. User management service
5. Workout management service
6. Reports management service
7. Exercise management service
8. Cache
9. Database - 2 nodes ( sharding on the basis of userid )

Flows involved

1. Add a user
   1. User signs up using mobile app ( sign up process is same for web browser also )
      1. We will use google oauth to simplify login and signup
      2. Once user signs up using google, we get a google_id from google's API. We use the google_id as the external_provider_id and this is stored in our database
      3. We get a code and our backend will exchange the code for token with Google's token endpoint
      4. We create a session token and this is passed around for any API that needs authentication
   2. The user is then showed a page with a form to fill in some basic details such as name, age, sex, date of birth, height, weight and username.
   3. We perform a validation if the username is already taken using a bloom filter or alternatively if we use a database like cassandra, it would use the same bloom filter internally to compare and set.
   4. This information is saved in our database

1. Login as existing user
   1. User logs in using mobile app / web browser
      1. Login redirects to google authentication
      2. Once successfully authenticated, we get the google_id
      3. We look up based on the external_provider_id and see if user already exists, then we load his home page , else we redirect to create new user page

• Log a workout
  • User adds a workout using the add workout button
  • We start a new workout with a timer running that will be used to indicate the total time spent in that workout
  • The workout page provides option to add new exercises
    • We make call to the cache to fetch all the latest exercises ( paged way ). if cache miss occurs, we retrieve from the DB and update cache.
  • User can add exercise and then we provide the option to add a set and the no. of reps for that set along with the weight if applicable. User can add how many ever sets he wants for that exercise
  • Once user adds a new exercise, it means he is done with the previous exercise, we now call the update workout with the latest data and update the current workout. We don't do it for every set to prevent an overload and also we don't wait for the user to finish the entire workout so that in case the app is closed or crashes due to whatever reason, we will still retain the workout till the last completed exercise.

{

user_name: bigdaddyv,

date: 2024-09-04 13:42:22 +0530,

exercises :

[

{

exercise : "Hammer curl",

sets:

[

{

weight: 10,

reps: 12

},

{

weight: 10,

reps: 12

}

]

},

{

.

.

.

}

]

}

• Report
  • Get workouts between a date range
    • Reports are available from both web and app version
    • The call comes from the UI to the API gateway, which then directs it to the Reports service. \
    • Reports service will first try to load from the cache. The cache key would be a combination of the user_id and the date of the workout. this cache will be valid for one day since it's very likely that the next day the user might ask for a different day's report.
    • In case of cache miss, Reports service then loads the data from the database. ( the database is sharded based on the userids. We will distribute the user id to the nodes using consistent hashing ). We also update the cache
    • Reports are sent back to the UI for the user to verify
  • Get vitals between date range
    • This service is used by the user to understand how his vitals like Body fat percentage or weight have progressed over time.
    • These vital readings are stored in the database. sharded based on the user id
    • We try to retrieve from cache first. Here the cache key will be based on the date and the user id. Cache will be invalidated after a period of 10 days.
    • If cache miss occurs, we will retrieve from DB and update cache and send the results to the user.

Offline flow

• When the user is offline, we continue to update the data on the device. The idempotency key is a combination of the user id and the start time of the workout. This will ensure that we update the right record once we are back online. Since we trigger the sync ourselves, we can ensure that there are no duplicate records being sent

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

Reports service

• Report
  • Get workouts between a date range
    • Reports are available from both web and app version
    • The call comes from the UI to the API gateway, which then directs it to the Reports service. \
    • Reports service will first try to load from the cache. The cache key would be a combination of the user_id and the date of the workout. this cache will be valid for one day since it's very likely that the next day the user might ask for a different day's report.
    • In case of cache miss, Reports service then loads the data from the database. ( the database is sharded based on the userids. We will distribute the user id to the nodes using consistent hashing ). We also update the cache
    • Reports are sent back to the UI for the user to verify
  • Get vitals between date range
    • This service is used by the user to understand how his vitals like Body fat percentage or weight have progressed over time.
    • These vital readings are stored in the database. sharded based on the user id
    • We try to retrieve from cache first. Here the cache key will be based on the date and the user id. Cache will be invalidated after a period of 10 days.
    • If cache miss occurs, we will retrieve from DB and update cache and send the results to the user.