System requirements

Functional:

• User can track their physica activities: jogging, and doing exercises.
• Users can set goals for the next train: distance,time of doing exercises,and max heartbeats.
• Users can collect these training metrics: speed, distance, and heartbeats to see their progress and train more effectively.

Non-Functional:

• The system should be highly available to process the mobile client request.
• If the System is down, the client application may work for some time to track and collect user metrics as long as the system is down. When the system is recovered, the client application sends their data.
• The system may be eventual consistency and show actual data a bit later.
• The system should be fault tolrenat and it shouldn't lose the user data. The mobile application should make a backup of user data.

Capacity estimation

Let's count we have 100 million of active users.

Every user work out 2 time a week for 1 hour.

User transmits such information every second about 100 bytes:

• timestamp 8 bytes
• location 16 bytes
• speed meter per second 3 bytes
• hearbeet 3 bytes

So it's 720kb per week for one user

72 terabytes for 1 week.

150 terabytes for 1 year

300 terabytes(one copy for replication) for 1 year or 1500 terabytes for 5 years.

API design

startTrain(apiKey,location,timestamp) starts new training.It returns trainingId.

track(apiKey, trainingId, timestamp, user metrics) passes the user metrics to server.

finishTrain(apiKey, trainingId,timestamp) finishes the current training, it returns the final result of the workout.

Database design

The primary data model for this system is three tablets: one table is for the users, the second is for workouts, and the third is for workout data.

It doesn't require strong consistency for users and workouts. We write the user and workout data to NOSQL like AWS Dynamo.

User table:

id(10 bytes)

first and last names (200 bytes)

phone number (50 bytes)

email (100 bytes)

createdAt (8 bytes)

Workout table:

id (10 bytes)

description(300 bytes)

userId (10 bytes)

startDate(8 bytes)

endDate (8 bytes)

Workout data:

id (8 bytes)

userId (8 bytes)

trainingId (8 bytes)

latitude: (2 bytes)

longitude (2 bytes)

date (8 bytes)

heartbeat (2 bytes)

elevation (8 bytes)

Goals table:

id (10 bytes)

userId (8 bytes)

date (8 bytes)

text (1000 bytes)

Analytics table:

id (10 bytes)

userId (8 bytes)

trainingId (8 bytes)

start date (8 bytes)

end date (8 bytes)

min speed (2 bytes)

max speed (2 bytes)

average speed (2 bytes)

distance (3 bytes)

The analytics table will be updated after the user finishes the workout.

It needs to create the indexes to search in DB faster.

High-level design

See the diagram from the high-level architecture.

API Gateway provides DDoS protection and TLS termination, and forwards request to the right service nodes.

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?