System requirements

Functional:

• users can set goals
• users can input physical activities
• users can monitor progress

Non-Functional:

• consistency: we want the user's data to be there
• availability: user wants to see calculations as they post them

Capacity estimation

RDMS should be enough

API design

add_activity(user_id, activity, goal)

• adds an activity to monitor, optional goal
• activity can either be from list or custom

add_goal(user_id, activity_id)

• adds or modifies activity goal

update_goal(user_id, goal_id)

• updates goal

get_activities_to_display(user_id)

• gets all activities and corresponding goals to display in dashboard

get_workout(user_id, activity_id, date)

• sets workout for an activity

add_workout(user_id, activity_id)

• adds workout to activity

add_status(user_id)

• adds status information

get_statuses(user_id)

• gets history of statuses to display

Database design

user:

id: UUID string (16 bytes)

activities: FK activity ids

activities_to_display: FK activity ids

statuses: array of status_ids

activity:

id: UUID string (16 bytes)

user_id:

name: string 16 bytes

workouts: array of workout ids

goals: integer 16 bytes

status:

id: uuid

user_id: uuid

blood_pressure: string

weight: integer

date: string

goal:

id: uuid

activity_id: uuid

status: (ENUM ongoing, failed, met)

amount: integer

workout:

id: uuid string 16 bytes

activity_id: uuid 16 bytes

date: string 16 bytes

High-level design

the client calls a server for all the functions, the server uses a database to update and fetch data.

because of the high volume of writes for adding "workouts" a job queue is used to update the data as not to overload the server.

Request flows

user uses the app to add or update data, this is sent to the server in a request and then the database is updated.

because of the large volume of requests to add workouts,

The user can also use the app to navigate to a dashboard with all their information which will show data from get_activities_to_display and get_statuses

Trade offs/Tech choices

I'm using an api gateway for authentication and routing, but it makes the app more complex

the app is very simple, but as it expands it could be more complex

Failure scenarios/bottlenecks

if the api gateway goes down then there is a single point of failture

Future improvements

as the application grows we can add more monitoring data