Requirements

Functional Requirements:

• Log workouts
• View history & basic stats.
• Sync across devices.
• DAU: Around 10 million users, as fitness apps can attract a large user base.
• Concurrency: At peak times, you might expect around 5-10% of DAU to be active simultaneously. This would translate to approximately 500,000 to 1 million concurrent users.

1. User Activity Data: Typically, activity logs and workout data are retained for at least 1-2 years. This allows users to track their progress over time and review historical data.
2. Personal Information: User profiles and personal data might be retained for as long as the user maintains their account, but it's good practice to allow users to delete their data upon account deletion.
3. Aggregate Data: For analytics purposes, aggregated data can often be retained indefinitely, as it doesn't identify individual users.
4. Type of Activity: Running, cycling, swimming, weightlifting, etc.
5. Duration: Total time spent on the workout.
6. Distance: For activities like running or cycling, the distance covered.
7. Calories Burned: Estimated calories burned during the workout.
8. Heart Rate: Average and peak heart rate during the workout (if applicable).
9. Repetitions and Sets: For strength training, the number of sets and reps performed.
10. Workout Intensity: User-defined or calculated intensity level.
11. Location: GPS data for outdoor activities, if applicable.
12. Date and Time: When the workout took place.

Non-Functional Requirements:

• Reliable
• Low latency < 300 ms
• High availability
• Scalable

API Design

API to record stats and details from the device , device acts as edge and keep pushing data server

1. Create sessions POST -/User/ {id}/workouts/session and returns session id
   1. Input - Work out - name , location - lang and lat , start_time, meta data about workout
2. Post the work out statistics details Post - /User/ {id}//workouts/session/{id} - return success or failure - based on the workout type stats change , heart rate and time stamps are constant
   1. input as heart rate , work out stats { srtides , reperations , langlats } , time stamps(start and end time), calories
3. Get workout summary - /User/ {id}//workouts/session/{id} /summary
   1. return work out aggregated summary
      1. Duration
      2. Calories
      3. heart rate ranges
      4. other health metrics
4. Post - /User/ {id}//workouts/history - fetch all user workout histroy
   1. start and end dates as input
5. Post- /user/{id}/workouts/synch

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.

1. Edge Device - records the workout details
2. Send details frequently as aggregated data interval of 30 seconds or more
3. Server - which edge device sends and receive data
4. Server will be horizontal scalable based on the number of requests
5. Data base - Persist the Data
6. Database - as the data more of time series in nature we can use time series database
7. Database - Time series data helps in quick aggregations
8. End of the Session - Fires message event saying workout session completes for analysis
9. Analytic service will be scaled based on the the queue depth
10. Improve workout service - as payloads are smaller and more number of requests we can use the virtual thread to handle more request per service
11. Database - will be sharded based on the geo location of user
12. Database - time series databases are segmented by time stamps range , can use the 6 hours as segment
13. Edge device has retry mechanism for all request - Exponential retries
14. Edge device in case of offline - it accumulates data for brief time period like 7 days
15. On Return of internet - it synch data using synch api
16. Synch API - Generates the Synch id and keep pushing the data to Server based on workout session
17. Synch API - Data will be sent by session
18. Synch API - Data will be sent to message queue
19. Synch API - based on message depth the workers will be scaled
20. During Offline synch - based time duration and work out type duplicates will be handled
21. Analytic services - Eventual Consistent , as data looks at history and current data , updates the stats. There will be lag to get more analytical data of 5 mins. Precomputed history stats will be used to Analyse the current data
22. Cache - Used to cache todays and last one week data of user for frequent access
23. Edge Device - Aggregate the for frequency of 30 seconds or more and send data to Server
24. Bulk Uploads - handled through queue and asynch process of using queue depth and number of workers
25. Bulk Uploads - Data duplications avoided through Duration and work out type as combination, check data base for duplication using above
26. Database choice time series - For high frequency details fof workout with frequency of 30 seconds or lower
27. Database choice for users - RDBMS Postgres for the all user details
28. Database choice for analytical records -RDBMS Postgres for the analytics and aggregated history
29. Cache - Redis
30. Cache - will be refreshed as soon as new sessions are completed or updated

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.

1. Workout service - Creates session id on the every new work out starts
2. Workout service - Records the details under the session id
3. Work out service - On Completion of session , it updates duration of workout
4. Workout service - Records the session details in the Postgres
5. Workout service - On completion of each sessions - fire the analytic event
6. Workout service - Offline synch - helps in case device is not connected
7. Workout service - Offline synch - Creates Synch ID
8. Workout service - Offline synch - Update the data under this - Segmented data will be send by edge - to better use of network , combining multiple sessions data or single session data
9. Workout service - on receiving of data , it will be put in to queue for processing
10. Workout service worker - will be scaled on the depth of queue
11. Workout service - Maintains the check point of data received for synch id
12. work out service - Incase of again disconnection - edge can request for check point or service can respond with check point in case receives duplicates
13. GPS Location - Receiving the data out of order , we persist the data against time stamp . Databse will store in the order of time stamp , which will be used for all analytical and stats purpose
14. In case of missing data - use interpolation of data to get missed points