Requirements

Functional Requirements:

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

Non-Functional Requirements:

• The application should be highly available
• Logged workouts should be strongly persisted
• Viewing history and stats should be quick with less than 10 milliseconds response times
• Sync should happen in background as soon as user logs a workout and be consistant without duplicates on other devices
• A user should be able to view only their history and not other users history

API Design

1. createUser - Creates a new user
2. login - Authenticates a user and logs them into our app
3. logWorkout - logs a workout session details
4. viewHistory - retrieves workout history of the user
5. viewStats - retrieves workout stats for the user

High-Level Design

Capacity estimates:

User data - username, password, name, age each record at most 1 KB.

Workout data - date, duration, exercise name, weight, calories burnt at most 2 KB

Assuming a user logs a 10 workout (one per exercise) once a day and we have 1 million daily active users and 5 million over all users, we will need:

Users table - 10 ^ 3 B * 5 * 10 ^ 6 = 5 GB overall.

Workout table - 2 * 10 ^ 3 B * 10 * 10 ^ 6 = 20 GB of writes daily.

On average a user would see the their history/stats 4 to 5 times a day. These can be stored on the device for low latency access and will be updated every time a new workout is logged, reducing read load on our DB. Stats would be better to compute them on the fly whenever a new workout is logged. This will be compute heavy but can be handled using fast algorithms like prefix arrays and segment trees. For a particular user we would at most have 4000 logged workouts in a year, computing stats at this scale is fast using the aforementioned algorithms.

So we have a write heavy system that stores around 700 TB data annually. We can optionally delete workouts older than a given timeframe (say 1 year) to optimize our storage needs. Alternatively we can put older workout data in a deep sleep data store like Amazon S3 infrequent access and show history/stats for the past 1 year only. When user asks for a longer history/stats, we can get older data and compute them.

Since we have a lot of data and we only need eventual consistency (we can wait for a few seconds for data to sync), we can go with a NoSQL database like MongoDB. Logging everything to the database gives us instant sync capabilities and a user can login on another device and see fresh data/stats.

High Level Application Components:

1. User interface / mobile app
2. Load balancers distributing traffic
3. API backend (core application logic)
4. Database

Our load balancer and backend are stateless so we can easily scale them using containers. Our database will become a bottleneck due to the amount of reads and writes. It makes sense to shard the database by location as people mostly workout at home or local gym. Such horizontal scaling distributes our load roughly equally.

For authentication we can use email or allow third party SSO using Google, Apple etc.

Flow of a logWorkout request:

1. User logs a new workout on the device
2. Device sends the backend a request with the workout information
3. logWorkout service saves the workout in the database and triggers a stats calculation
4. The new stats are pushed to the device

Flow of a viewStats request:

1. User clicks stats button
2. Device shows the precomputed stats