Requirements

Functional Requirements:

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

Non-Functional Requirements:

• Read heavy application, writes happen roughly the frequency of gym training (4-5 times per week for a specific user)
• Needs to be scalable in time, the logs will grow in size as time goes on
• Low latency when viewing history
• Eventual consistency needed to support syncing across multiple devices

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

POST gym/v1/workout

{

date: str

workout_exercises: [

{

exercise: str,

sets: int,

reps: int

weight: int

}

...

]

}

GET gym/v1/workout

Query params - filtering by time

-> WorkoutExercises

GET gym/v1/stats?time=?

-> {

days_with_workout: int

total_volume: int

volume_progression: float (percentage)

weight_progression: float (percentage)

}

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

The clients request goes through Load Balancer then API Gateway.

Workout Service is responsible for logging workouts and getting history. It writes to DynamoDB and Redis Cache with TTL. When user reads the history, we first check if it's in Redis then in DynamoDB

A Cron ETL Job regularly fetches data from DynamoDB that is old (e.g. more than 1 year) and puts it in a Cold Storage (Magnetic-Tape datacenter or Amazon S3 Glacier).

A Status ETL Job regularly gets data from DynamoDB and creates snapshots of statuses for active clients. These statuses are then stored in a specific DB.

If a client requests the status for a specific duration, first check if we can provide it based on the StatusDB. Otherwise build it at the time of the request by fetching data from DynamoDB and optionally the cold storage if the user asked for very old data.

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

DynamoDB Workout table:

client_id: primary key

timestamp: sort key

workouts:

DynamoDB Status table:

client_id: primary key

snapshot_start_date: sort key

snapshot_end_date:

days_with_workout:

total_volume: int

volume_progression:

weight_progression:

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

Workout service:

• uses a Redis Cache to optimize reads. Reads are much more frequent
• To ensure availability we use a dynamoDB database containing the data about workouts.
• When using multiple devices data can occassionally be stale. this is expected and better than returning error
• use client_id as primary key in order to consistently route requests for a specific client to the same shard
• Since DynamoDB can potentially get very large we use an asynchronous Batch Cron ETL job to move data to Cold storage

Status Service:

• A Status ETL Job regularly gets data from DynamoDB and creates snapshots of statuses for active clients e.g for every week.
• When clients request status for last 1 month, we can fetch 4 snapshots from the DB to return the response faster.
• Otherwise build it at the time of the request by fetching data from DynamoDB and optionally the cold storage if the user asked for very old data.
• These statuses are then stored in the status DB