System requirements

Functional:

• Track KPIs for user activies
  • Timing
  • Distance
  • Calories
  • Heart rate
  • Sessions
  • ...
• Dashboard to review goals and progress

We will focus to some KPIs only: timing, distance, heart rate

Non-Functional:

• Some KPIs can be recorded with a few seconds of delay
• 30 to 90 days of history for detailed records
• More history for long term trends (goals etc.)

Capacity estimation

Each session will consist of many records to track the evolution of KPIs

SessionId (int 4 bytes)

Timestamp (int 4 bytes)

PositionLat (decimal 4 bytes

PositionLong (decimal 4 bytes)

HeartRate (1 byte)

Total 17 bytes

Sessions duration is around 30~60 minutes

We will record the KPIs every 10s

So 360 records per sessions for a 60 minute session

50K users with a session/day

18M records per day

1.62B records for 90 days of history

1,62B * 17 bytes = ~26GB of data

API design

/startsession

Params: userId

Returns: sessionId

/stopsession

Params: sessionId

/track

Params: sessionId, lat, long, hr

/viewhistory

Params: userId

Returns: sessions

Database design

Table Sessions

• [PK] sessionId
• [FK] userId
• start_datetime
• end_datetime

Table Tracking

• [FK] sessionId
• timestamp
• lat
• long
• heartRate

Table Users

• [PK] userId
• email
• password
• first_name
• last_name
• registration_date

High-level design

A load balancer will helps balancing traffic accross multiple servers

Backend services are splitted in two:

• A general purpose webapp that answer most of the requests
• A dedicated service for the tracking

Data points for tracking are pushed to a queue and processed asynchronously

Some data are cached to speedup displaying the activity reports, particularly for old data that don't change

A report service (scheduled service) can precompute the dashboard for users activities and put the data in cache

Request flows

• User logs to the app
• User start a session on the main service
• User push tracking data point to the dedicated tracking service
• User stop a session by calling the main service

Detailed component design

• Tracking can be done using a web socket between the app and the tracking service
• Database can be partionned by range using datetime

Trade offs/Tech choices

Strong consistency isn't required here so a NoSQL database can be ensivaged to accomodate future growth. Using a time series database can be a good choice to store tracking data points.

Failure scenarios/bottlenecks

The bottleneck can be the big amount of tracking data point if many users start their session around the same time

The queue can help to reduce the pressure on database during these peak of activity

If the communication fails between the app and the tracking service, the data can be cached locally and pushed later

This can be also useful for when the user if offline because the a connectivity loss (particularly true for cellular network)

Future improvements

• Add more KPIs (calories burnt, steps etc.)
• Analytics servers for global statistics