System Requirements

Functional -

1. Client is a mobile app on iOS and Android
2. Types of activities are running, walking, cycling and lifting weights
3. User can set goals by frequency (number of times per week), duration (for example, 5 miles per run, 20 mile per bike ride), intensity (lift x weight)

Non-Functional -

1. Scalability - System should be able to a large number of users in the future
2. Availability - System should be available at all times
3. Consistency - We are aiming for eventual consistency here, prioritizing availability over consistency
4. Fault Tolerance
5. Privacy - User data is sensitive and should be handled appropriately

Capacity Estimation

1. We assume that the service has 100 million daily active users
2. Each user does one workout every day
3. Each workout takes 1 KB of data to store
4. Thus, each day, we generate 100 ^ 10^6 * 10 ^3 bytes of data = 10^11 bytes of data, which is 100 GB of data each day
5. Over a month, we need 3000 GB data or 3 TB
6. Over a year, we need 36 TB data
7. Service runs for 10 years, needs 360 TB data
8. Factoring in replication, service needs at least 1000 TB or 1 PB data
9. We serve 10 ^ 8 request per day, each day has roughly 10^5 second, thus queries served per second is 1000
10. Peak queries per second would be 5 * QPS = 5000

API Design

1. Post workout
   1. Posts workout data to the service and updates goals
   2. POST
   3. /workout/post
   4. Takes in a JSON as an argument which would list the type of workout and other metrics that are needed to track it
   5. Returns 2XX status code in case of success, 4XX in case of failure
2. Get workout data
   1. Gets the information on the last N workouts
   2. GET
   3. /workout/fetch/:N
   4. Takes in the parameter N, if N is not present, we fetch the information on the last workout
3. Set Goal
   1. Sets a goal for a user
   2. POST
   3. /workout/goal
   4. Takes in the goal in the form of a JSON and creates a goal

Database Design

1. We are storing a large volume of data that is semi structured
2. Our data is both read and write heavy
3. We can use a key value store where we map all of the information of the user to his unique user ID
4. We can cache the last N workouts of the user since that data is not subject to change

High-Level Design

1. Client connects to the load balancer
2. Load balancer redirects the request to the API Gateway
3. Based on the type pf request, API Gateway redirects request to the Goal service or the Workout service
4. In case of the goal service, we first access the cache to see if the data is present there, otherwise we hit the database
5. We decouple all of our components using a messaging queue

Request Flows

sequenceDiagram Client->>+Workout Server: start_workout() Workout Server->>+Client: Ack Client->>+Workout Server: update_status() Workout Server->>+Client: Ack Client->>+Workout Server: finish_workout() Workout Server->>+Client: Ack Workout Server->>+Database: store workout via Message Queue Client->>+Goal Server: get_status() Goal Server->>+Client: goals_status(): % goals achieved, congratulatory messages

Detailed Component Design

1. For our load balancing strategy, we use index based Layer 4 load balancing so that users are routed to the nearest server to reduce latency
2. API Gateway does rate limiting and lets the user know when they are being rate limit gracefully
3. We use log based message queues since we do not want to lose user data
4. We cache a user's goals and his last N workouts, where N is a configurable parameter. We invalidate the workouts whenever we record a new workout for the user. We invalidate the goals of a user from the cache when the user adds a new goal. For other cases, we use Least Recently Used as our cache eviction strategy

Trade Offs/Tech Choices

1. We use Mongo or Dynamo as our database of choice since we are dealing with a lot data and our data is not very structured, we are also opting for eventual consistency
2. For our cache, we use Redis
3. For our messaging queue, we use Apache Kafka

Failure Scenarios/Bottlenecks

Future Improvements

1. Users should be track how far along their goal they have progressed
2. Letting the user know when they have hit a goal