System requirements

Functional:

• Able to get the live workout data (heartrate, BP, distance ran calories burned) to server
• Maintain WebSocket connection to send and receive data continuously
• Process the data quickly - Use snowflake or other tools to perform analytics quicky
• Should notify for the goals to complete like completed x number steps, ran x number of Km.
• Can have overall leaderboard for ranking with friends.

Non-Functional:

• Connection should be made continuously and make efficient retries.
• Need to store the data in client application until data is sent to server.
• Minimal analytics can be done from client for user can see data quickly.

Capacity estimation

• The data is the key points in fitness application and it deals with timeseries data, So better to go with NOSQL data structure.
• Data like heart rate, BP are continuously monitored but walking running are no steps or km during an hour.
• Lets assume 1000 users which writes to db of 300bytes perday can cost 1000*300bytes perday.
• we can delete the historic timeseries data based on user confirmation.
• We need separate analytics engine to reduce load from db and server.
• Scaling the db horizontally is important.

API design

• Post - /workouts -> [WorkoutRequestDto]
  • WorkoutRequestDto - { workout : "Run", data : {heartrate : "", BP :"", CaloriesBurn :"" , currenttime : "", workoutstartTime :"", workoutEndTime : ""}
• Get -tracking{userID}/workouts?from=''&to=''&type-> data of workout for given time
• Get -tracking{userID}/workouts?from=''&to='' -> all workout data of given time
• Get-tracking/{userID}/summary - today workout summary
• Get-tracking/{UserID}/summary?from=''&to=''
• Get-tracking/UserID}/summary?from=''&to=''&type

Database design

User table -

userId - pk

name

age

mail

workout :

id

userId - FK

workoutType

timeseries data no sql :

id,

workoutId,

datapointName

value

unit

time

High-level design

1. Watch or device to collect and send data continuously to server
   1. WebSocket for Live data transmission
2. Server get and parse the input - Like validation, formatting
3. Save to DB
   • Basic User and Workout - Mysql
   • Timeseries data - MongoDb
4. Put the input into analytics engine - A separate service that process the mongoDB data.
5. Save cumulated or aggregated data from analytics - Can save the data as SQL from processed timeseries data.

AWS Redis : Cache the user related info which do not change frequently.

Need to store the datapoints in client side until it connects to internet.

Queues and notifications

• AWS SQS :Based on user confirmation a separate ASYN job which deletes the records if matches historic records for storage optimization.

• AWS SNS : Based on user goals send notifications.

Request flows

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

Detailed component design

• Automatic deletion
  • We need to push the today delete data to Queue and trigger ASYNC job to poll the Queue and delete the data.
  • By this way we can reduce the server load and optimize storage

Trade offs/Tech choices

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

Failure scenarios/bottlenecks

• We can create disaster recovery setup and Auto scaling to support bottlenecks
• Only timeseries data can be overloaded which can solved by Sharding in mongodb.

Future improvements

• Leaderboard support to compete with others.
• Import and export data
• Sharable format to post in social media.