Requirements

Functional Requirements:

• Log workouts
• View history & basic stats.
• Sync across devices.

Non-Functional Requirements:

• Availability: The System should be highly available.
• Consistency: System should be highly consistent where each activity reading should be capture and reflect on the user screen. No duplicate records must be created.
• Durability: Once data is created needs to ensure that data never lost
• Performance: Workout metrics should be reflected quickly to provide a near real time experience to the user.
• Reliability
  1. The System should behave correctly and deliver the functional requirement even in case of failure, request spikes and other outage.

API Design

• Log a workout
  1. System should capture the user workout details.
  2. HTTP POST: /api/v1/workout
  3. Request Body: {

"workouttype":"".

"workoutmetadata":{}

}

d. Response: {status:"", message:""}

• Get the workout history
  • User can get the workout details by workout type, for a date and time
  • HTTP GET: /api/v1/workout/{workout-type}/{startdatetime}/{enddatetime}
  • Response: {workouttype:"", metadata:{}}
• Workout stats
  • User can get the statistics of the specific workout
  • HTTP GET: /api/v1/workout/{workout-type}
  • Response: {workouttype:"", stateFor="Daily/Weekly/Monthly" metadata:[{date:"", caloriesburnt:"",highhartbeats:"", lowhartbeats:""}]}
• Synch the workout details with backend
  • The workout data will be store at the local storage for a specific interval or when the user is offline. once user is online of after a specific interval user data will be synch to the backend system
  • HTTP POST: /api/v1/workout/synch
  • Request Body: {

"workouttype":"".

"workoutmetadata":{}

}

• • d. Response: {status:"", message:""}

High-Level Design

1. On the high level there will be 3 main services
   1. GPS Tracking
      1. It maintains the GPS locations and also user activities locally. When User is offline or till the time user finish the activity.
      2. Once user is back to online or finish the activity it opens the websocket connection with the activity tracking service.
      3. Once WebSocket connection is established it sent the data in batch and then activity tracking service will process it ahead.
   2. Activity Tracking
      1. Activity tracking service receives the GPS tracking data and the activity data in batch.
      2. The Activity data will be persisted into the database and once persisted the data publish to the Kafka as a event to the other services such as Goal Service, Activity aggregating service.
      3. The GPS tracking data will be maintains into the S3 object storage.
      4. In all the cases user id and the activity date and time will be use as a primary key so that no duplicate data will be process.
   3. Dashboard service
      1. This service is responsible to provide a data requested by user for displaying in the application dashboard.
      2. The data can be the Activity report for a day, Week, Month.
      3. In this case it will mainly make use of Cache lookup before it makes the actual DB call.
      4. The data will be aggregated periodically by the aggregated service and maintain into the cache with userid as a key.
      5. For a latest data like ongoing activity the Cache TTL will be every 30 seconds, for a weekly TTL will be longer such as 7 days.

Following is the high level flow of the user activities.

1. Workout details of the user will be store locally and gets recorder every 2 seconds.
2. The workout details which is persisted locally will have a retention of 7-10 days depending on the local storage capacity.
3. By Maintaining the workout details locally user will get the latest data reflected without any lag.
4. The locally store data will be synch to the backend server once user is online or after a specific interval such as every 1 hours.
5. While synching the data the data will be sent as a batch and process in batch to achieve the low latency.
6. Once data will be process successfully to the backend system it can be marked as archive and will become ready for cleanup.
7. Before cleaning up the data system should ensure that it has been sent to backend as a part to synching process.
8. There will be a batches execute for each activities for a specific interval which aggregate the data and persist the summary of each user, so that user will get the workout summary report/statistic from the pre calculated data.
9. Data base shading should be base on the type of activity, it can be the Hash Of Workout type so specific DB instance will be used for a specific Workout type.
10. The database tables will be partition by daily so that the processing operation happen on the small amount of data which improve the query performance.
11. Caching can be used to store a top athletics workout data so user can see and set the goal by looking to top athletics metrics. The TTL will be daily of these data as this data is not specific to the user so there no need of frequently updation of the data.
12. In case of spike in the traffic the workout-synch-service instance can be scale automatically as a part of horizontal scaling

Detailed Component Design

1. Client side storage: This is the most useful component to store the user data locally when use is offline or to persist the user data to the nearest location so that it gets reflected quickly to the users devise which give user near real time experience. the Synching of the client storage data will be happen with the backend application after every specific interval such as 1 hour or 6 hrs as per configuration.
2. API Gateway: API gateway help in case of routing, request validation, rate limiting and redirect the request to a appropriate instance of the workout-synch-service. the API gateway will make sure that load balancing happens appropriately and no instance gets overloaded.
3. Activity-tracking-service: This service gets the user data in batch as a part of synching process. there will be multiple instance of the service to achieve the availability and sharing the traffic during the synching process. The data will be persisted in the Database tables in batch to reduce the network calls and reduce the latency. Once data is persisted into the database the kafka event will be generated and publish to the downstream services such as goal service, notification service and Aggregator Service.
4. GPS-traking-Service- GPS data will be sent to backend application using a web socket. Clients opens a web socket and share the GPS data this data will be buffered at the backend service and push to Object storage after a specific interval and successfully uploaded data will be trimmed from the buffer. The GPS data will be much noisy data so it will be buffer at the client side or local storage and will be send to backend system in chunks after specific interval or when user is online. this will help to manage a large amount data.
5. Database: will be shared based on the hash of the workout type. This will help to distribute the load across the multiple database instance. Every data will be synch once as the status of the data will be maintain by the local storage so three will be no duplicate data send to backend service. Database shading by workout type and table partition will help queries to execute on the smaller part of data.
6. Batch/aggregation Processing: There will be multiple batch processor which pre calculate the user stats at the specific interval so that when user request for a statistic it will be return from the pre calculated data. The batch processor will be trigger after every specific interval and performs the aggregation on the user collected data. also the aggregated result will be persisted in the cache so that it will be access faster. as a part of cache miss it execute the aggregation query, put the result into cache and return to the client