System requirements

Functional:

Although a full-fetched Fitness Tracking application would be able to do lots of different things, we'll concentrate on it's core functionality:

• setting goals (in terms of a number of workouts per week)
• starting/stopping workouts
• monitoring goals progress

Non-Functional:

• we want high availability and low latency
• scalability, given growth expectations

Capacity estimation

We'll need a storage for users, users' goals and users' workouts.

Assuming, 10k DAU at the start and up to 50k DAU in a year we can roughly estimate our storage requirements:

• average first year's DAU ~30k
• each user creates, say, 1 goal per week, which takes 128B, so ~6kB per year
• each user logs on average 4 workouts per week, each taking ~256B, so ~50kB per year

In total we'll need very modest 3*10^4 * 6*10^4 B = ~2 * GB of storage for the first year.

API design

We'll need the following API in the system:

POST v1/goals/new - returns a status code and some metadata (id,

{

id: string,

user: string,

type: string,

created_at: timestamp

}

GET v1/goals/user/{user_id} - returns paginated set of a user's workouts

{}

POST v1/workouts/start - return a workout id

{

user: string,

started_at: timestamp

type: string

}

POST v1/workouts/{id}/readings - returns a status code

{

heart_rate: int,

coordinates: ,

...

}

POST v1/workouts/{id}/finish - returns a status code and some metadata

{

finished_at: timestamp

}

POST v1/workouts/new - returns a status code and some metadata

{

user: string,

type: string,

indicators: [ind1, ind2, ... ]

started_at:

}

GET v1/workouts/user/{id} - returns a paginated set of a user's workouts

Database design

We'll have a NoSql storage for all our entities, since we don't need strict consistency guarantees or relational queries. And also we can anticipate changes in the schemas, since we're in the early stages of development of our app.

We'll store the following entities:

Goal - supports only goals for a desired number of workouts per week

{

id: string,

user: string,

type: string,

target_value: int

}

Workout

{

id: string,

user: string,

duration: int,

indicators: [ind1, ...]

start: timestamp,

end: timestamp

}

We'll need the following indices:

• on goals by user
• on workouts by user, start time, end time and duration

High-level design

We'll have a load-balancer with a rate limiter facing our system's clients requests. Right behind the load balancer will be an API Gateway routing user requests to the proper services:

• User service - responsible for creating/updating/retrieving user data (we won't dive deep into the service)
• Goals service - it handles request for creating and updating user goals (e.g. monitoring progress)
• Workouts service - handles requests for starting/finishing and retrieving user's workouts.

Each service will have its' own dedicated storage. And all needed aggregation will be handled on the services level.

Request flows

Let's take a closer look at managing workouts flow:

• user sends a request for starting a new workout, it gets routed to the workouts service, which creates a new record in the storage
• after some time user sends another request to finish the workout, which again is dispatched to and handled by the workouts service
• it updates the workout record in the DB
• it updates (synchronously or asynchronously) data in goals storage
• user may want to list all of their workouts, so they will send a request for retrieving them
• workouts service can just get all workouts by user from a read-only replica of the workouts storage

Detailed component design

Let's focus on a workouts service, as it seems to be the service with the most load:

• we've decided to go with a NoSQL storage for our components, which provide capabilities to achieve high availability and scalability
• to further improve latency and consistency we can introduce read cache and sharding techniques
• to decouple workouts service from goals service (whenever we need to update goals data after updating workouts data) we will use asynchronous model here (namely queue of requests) and probably some fallback strategies for achieving read-your-writes consistency for user goals requests

Trade offs/Tech choices

• Since we can anticipate write-heavy load profile, we will go with a distributed and highly available NoSQL storage. That will add some constraints on maintaining required consistency levels and not so frequent aggregation requests.
• 
  

Failure scenarios/bottlenecks

• whenever we want to improve throughput of our workouts service by introducing sharding we'll have to face some challenges with consistent sharding and scaling strategies. Depending on the load profiles and some analytical data gathered, we can shard based on user's id, workout timestamp, location. Some of that choices (e.g. using workout timestamp) can force us introduce aggregation logic in the service layer (e.g. getting all the user's workouts).

Future improvements