System requirements

Functional:

1. Activity Logging:
   • Users can enter fitness activities, including duration and calories burned.
2. User Account Management:
   • Users can create and manage their accounts.
   • Users can view all past activities as well as planned future activities.
3. Goal Tracking:
   • Users can set fitness goals for the future.
   • Users can monitor progress towards their goals, including how much they have left to achieve.

Non-Functional:

• High Durability: Users will expect that their data is durable and won't change or get lost over time, as this is the heart of the application and its usage
• High Availability and Scalability: Users want to be able to reach the application at peak times and no matter on how the user size grows
• Security: User data and authentication must be secured and is not allowed to intervene with other users data
• UX: App should be easy and intuitive to use
• Low latency: App should respond quickly to requests from the user

Capacity estimation

Back of the envelope estimations and assumptions:

Monthly active users: 1.000.000

Daily Active Users: 20-30% of monthly -> 200.000 - 300.000

Concurrent Users: at peak 5-10% of Daily active users -> 10.000 - 30.000

Read/Write Ratio: Considering the functional requirements, there should be a pretty balanced read/write ratio as users will both read and write a lot

API call estimation: avg. 5 API calls per session - 300.000 DAU -> 1.5 M API Requests Daily

API design

Looking at our data model, we'll need API endpoints for 2 purposes

• user related activities (operational things such as account management and authorization)
• workout related activites

let's desing the User API first. We'll design a RESTful API with the following endpoints:

• GET /user/:id
  • Returns a user profile by id
• POST /user -> body: {...userinformation}
  • Creates a new user
• PATCH /user/id -> bod: {...userinformation}
  • changes a user
• DELETE /user/id
  • deletes a user account
• POST /forgot-password ->body: {email}
  • resets a password
• POST /change-password -> body: {..auth}
  • changes the user password

Now that we have the User API designed, let's focus on the Workout API

• GET /workouts/userid
  • Returns all workouts for a user
• GET /workout/id
  • Returns a single workout
• POST /workout -> body: {userid, ...workoutinformation}
  • creates a new workout associated to a user
• PATCH /workout -> body: {userid, ...workoutinformation}
  • changes a workout associated to a user
• DELETE /workout/id
  • deletes a workout

The API should accomodate all needs of our functional requirements now.

Database design

Let's start with the most easiest unit:

We assume that the user can enter new Workouts Types, so he can track his own workouts. The data model would look like:

• id
• name
• created_at
• updated_at

This is pretty simple and should be enough to represent a Workout -> let's identify this model as workout_type

If we go next, then we should model a Workout now. Let's quickly recap on what we said as functional requirements for the workouts:

• Users can enter fitness activities, including duration and calories burned.

So let's model the data for this:

• id
• user_id
• workout_type
• date
• duration (optional)
• calories_burned (optional)
• created_at
• updated_at

Here we're referencing the workout_type entity from above. We're also referencing the user id here, as a workout belongs to exactly one user (the one who created the workout). A date is also crucial for the application. Duration and calories burned can be optional, based on the user preferences. Let's identify this model as workout

So if we recap now, we can fully represent a workout by meeting the functional requirements. What is missing is the user and the association to his workouts.

Let's model the user:

• id
• email
• password
• workouts
• created_at
• updated_at

Let's identify this model as user

So now we have our 3 entities:

• workout_type
• workout
• user

These entities with their relationships as described above will help us to design the application layer in order to meet all specified requirements.

Let's talk about the Database choice. We could have the option of choosing a relational database (such as Postgres) or a document based (such as Dynamo or Mongo). We can see that we have a One-to-many relationship between a workout and the user, and for the use case of our application, this is key. Both databases are a good choice, when considering One-to-many relationships. When we'd have many-to-many relationships, I'd definitely be in favor of using a relational database. But coming back to our scenario, I think it depends on the expertise of the owner and maintainer of the system to choose the database. for our case, we'll use a relational database - Postgres.

High-level design

flowchart TD

B["User App"];

n0["Backend Service"];

n3[("Database")];

n4[("Redis Cache")];

B --> n0;

n0 --> n3;

n0 --> n4;

Request flows

The High level design is pretty simple and provides the necesary high level components. First we'll have a User Application that acts as a client, Reaching out to the Backend where both user data and workout data are retrieved from.

As users will have multiple reads per day, a caching layer is introduced. The backend first checks the cache for workout data on the given user and reaches out to the database, if not found.

The retrieved data is then returned back to the client.

Detailed component design

flowchart TD

B["User App"];

n3[("User Database")];

n4[("Redis Cache")];

n5["API Gateway"];

n7["Workout Management Service"];

n8["User Management Service"];

n11(("Message Broker"));

n13[("Workout Database")];

n14[("Replica")];

n15[("Replica")];

B --> n5;

n5 --> n7;

n5 --> n8;

n8 --> n3;

n3 --> n11;

n11 -->|"notifies new user"| n7;

n7 --> n4;

n7 --> n13;

n13 --> n14;

n13 --> n15;

n7 --> n14;

n7 --> n15;

Trade offs/Tech choices

API Gateway and Separation of Backend Services

• Backend Services are separated into 2 as the API is designed in the same way
• Separation of concerns where the user management service just do user profile and authentication related things
• Workout Management Service focuses on the workout related things such as creation, tracking and such
• Each Service has a separate database for the separation of concerns and full ownership

User Management Service

• The User Magement Service is responsible for authentication and user profile management
• Has dedicated database
• all user related things, especially authorization is isolated and abstracted from the workout. So if in future new authentiation sytems will be implemented, the workout manageemnt service doesn't need to care
• A cache (redis for example) is introduced as well, just to take load of the database. the cache update should be fairly simple here as well, as it's not foreseen that a user will change the user profile extremely foten, so we won't likely experience no concurret data / cache update issues.

Keeping Workout Service informed about user creation / deletion

• A crucial trade off when separating the backend services is, that those are logically still combined from a data perspective (workout relates to a user!)
• So we need to have a mechanism to keep us up to date with the user ids that are active
• A message broker is introduced for this, in order to have this asynchronously possible
• Trade off: consistency issues. it could be that an async update will happen with some delay, where the user might not be able to create workouts, because the Workout Management service doesn't yet know about the new user id. This is a trade off, and better then having it synchronously, where a network issue or other failures could lead to the whole user creation being blocked. We want to aovif this and thus pay the cost of eventual consistency

Database Replicas and Cache for Workout Mangement Service

• As mentioned before, it's likely to have a balanc3d read/write ratio
• we expect around 1.5m api request per day
• Thus a caching is needed first of all to take load from the database and its replicas -> redis is introduced here
• We go for a leader based replication of the data as for the writes we just want to have a single database to be written to. Considering our requirement of durabiility, it's important to avoid any issues when for example having a multi-leader replication, which can violate the durability expectations. Allthough in this case we need to take care of failover (when the leader is not available), this complexity can be taken for the sake of having multiple read replicas as we expect high writes as well as reads. So one replica just focues on the wirtes while the other ones are there for reads

Failure scenarios/bottlenecks

The replication of databases always comes with tradeoffs. Single leader replication has the advantage of having no concurrent writes of the same data (as it happens only at one node), but it represents a single point of failure. So in this case we'd need deal with failover cases, where the leader fails. in worst case no writes would be possible anymore. So we'd need add the additional complexity to the system to detect a new leader.

Future improvements