Requirements

Functional Requirements:

• Log workouts and other physical activity (manually or through connection with wearable or fitness tracking apps)
• View history & basic stats.
• View workout examples
• Sync across devices.
• Set goals
• View goals and progress

Non-Functional Requirements:

• 99.99% uptime
• 1M DAU
• Low latency
• No duplicate records even if user attempts to submit multiple times
• No data loss

API Design

POST v1/users/{id}/workouts

body:

{ time_stamp: datetime

workout_type: str

data_source: str <-- manual or external device

duration: time

calories_burned: (optional): int

additional_metrics (optional): <-- store additional workout data when from wearable or external device.

workout_id: unique identifier for workout

}

headers:

Auth: JWT

POST v1/users/{id}/measurements

body:

{

weight: int

height (optional): int

sex (optional): str

}

GET v1/workoutresources

{

workout_name:

{

returns: S3 URL for rendering in client UI

headers:

Auth: JWT

GET v1/users/{id}/workouts/{id} <-- use id to filter for specific workout, or use query params for optional filters like date, workout type, etc.

headers:

Auth: JWT

POST v1/users/{id}/goals

body:

{

type: str <-- activity minutes or weight

name (optional):

due_date: datetime

goal: int <-- activity minute value or weight value

}

headers:

Auth: JWT

GET v1/users/{id}/progress

body:

{

goal_id: str

}

headers:

Auth: JWT

GET v1/users/{id}/dashboard <-- returns a summary of activity for specific time frame.

body:

{

timeframe: <-- time frame to view stats

}

headers:

Auth: JWT

High-Level Design

Client: Mobile Application

API Gateway: Used to handle auth, endpoint routing, and rate limiting.

Load Balancer: As we scale replicas of our services. the load balancer will evenly distribute requests, supporting horizontal scaling as needed. Will check for server health and route appropriately.

Services

1. User Service:
   1. Used for creation of new user objects
   2. Queries DB for basic user info
   3. Cache commonly queried info in Redis cache for better UI experience
2. Dashboard/Analytics Service
   1. Handles the generation of data for analytics by examining the USERS DB in the specified timeframe, and returning metrics like avg workout duration, avg workouts in time frame, etc.
3. Goals Service
   1. Handles creation of goals + storage in DB
   2. Handles goal querying
   3. Handles goal progress updates by cross referencing goal data with most recent measurement data from measurements DB
   4. Caches active goal metrics for faster UI rendering
4. Workouts Service
   1. Handles the creation and upload of workout data to workouts DB via message queue
   2. Each workout is stored as a time series
   3. Data is uploaded in chunks of 1 minute, so if user goes offline, only chunks missing need to be re-tried from local storage
   4. Message queue an handle workout upload async User is not waiting for response immediately, just ack Workouts service can process from summary metrics whether user has reached their goal
5. Video/Image Service
   1. Handles queries database storing examples of workouts (imgs/videos), media stored in S3 bucket

Notification Service

1. Handles notifying user when Goal is achieved
2. Message queue so notifs can be retrieved after user is offline for period of time.
3. Message DB (PostGreSQL) for creating message objects which will later be put into the queue.

Detailed Component Design

Scaling the services:

1. Load balancer will route to replicas of each service based on service health and user load, to ensure scalability (horizontally), orchestrated by Kubernetes. Each service will have 1 + N replicas to reduce the risk of having a single point of failure, where N varies depending on the load.

Scaling the DB:

1. As our user base grows, we can implement sharding for our databases. Using circular hashing, we can hash the workout id (for the NoSQL DB) or the userid (for the PostGreSQL DB, to route to the correct DB node, and make reads more efficient.