System requirements

Functional:

• user should register in order to use the app
• certain funcationalities are hidden behind subscription or payment
• user should be able to select certain sport type and enter data regarding that
• user should see their progress over time
• the app should provide notification to the user to remind workout etc.
• every sport type will have its own metrics to be tracked e.g

1. Running/Walking:
   • Distance (miles/km)
   • Duration (minutes)
   • Average speed (mph/kmh)
   • Pace (min/mile or min/km)
   • Calories burned
   • Heart rate (if applicable)
2. Cycling:
   • Distance
   • Duration
   • Average speed
   • Elevation gain/loss
   • Calories burned
   • Heart rate
3. Swimming:
   • Laps completed
   • Distance (meters/yards)
   • Duration
   • Stroke count (for advanced tracking)
   • Average pace
   • Calories burned
4. Strength Training:
   • Weight lifted (load)
   • Repetitions
   • Sets completed
   • Duration of workout
   • Time under tension
   • Calories burned
5. Flexibility and Balance (Yoga/Pilates):
   • Duration of each session
   • Number of poses practiced
   • Focus on breathing techniques
   • Calories burned
   • Heart rate
6. Sports (e.g., Basketball, Soccer):
   • Duration of play
   • Distance ran
   • Number of goals/successful shots
   • Calories burned
   • Heart rate
7. General Health Metrics:
   • Sleep quality and duration
   • Daily step count
   • Active minutes vs. sedentary time

• user should be able to edit their metrics
• user should be able to cancel their subscription and delete account
• the app will work with smart watches

Non-Functional:

• the app is available everyone on the globe via multi-zone deployments
• p99 latency is less than 100ms
• in case of a failure circuit-brakers will not use that instance

Capacity estimation

• the app will have read heavy usage
• there will be 1000_000 users per month
• 100_000 - 200_000 daily active users
• it will be then 200_000 / 86400 requests per second
• assuming that for a single sport type in average 5 metrics are there:
  • if every type of metric on average stores 10 byte of information
  • then for a single sport type 5 * 10 = 50 byte information will be stored
  • if we have 50_000 write requets per day then in total we will have 50 * 50_000 byte of information = 25_00_000 bytes it is 2.5 mb
  • monthly it is 65 mb more storage

API design

• authentication will be handled by a third party (google, facebook, instagram etc)

Add activity update:

POST/PUT /activity/activity-type/{activity-type}

every activity will have their own APIs and separated in the backend

response-codes: 200, 401, 403, 404, 500

response: activities of last 2 weeks for the user with pagination-id

GET /activity/activity-type/{activity-type}

response-codes: 200, 401, 403, 404, 500

this API will have pagination possibility

response: activities of last 2 weeks

there are things to add about the API, skipping for now

Database design

tables: running, cycling, swimming, strength training, flexibility and balance, sports (basketball, soccer etc)

column names will be the entries here under the sport types:

Running/Walking:

Distance (miles/km)

Duration (minutes)

Average speed (mph/kmh)

Pace (min/mile or min/km)

Calories burned

Heart rate (if applicable)

Cycling:

Distance

Duration

Average speed

Elevation gain/loss

Calories burned

Heart rate

Swimming:

Laps completed

Distance (meters/yards)

Duration

Stroke count (for advanced tracking)

Average pace

Calories burned

Strength Training:

Weight lifted (load)

Repetitions

Sets completed

Duration of workout

Time under tension

Calories burned

Flexibility and Balance (Yoga/Pilates):

Duration of each session

Number of poses practiced

Focus on breathing techniques

Calories burned

Heart rate

Sports (e.g., Basketball, Soccer):

Duration of play

Distance ran

Number of goals/successful shots

Calories burned

Heart rate

High-level design

• client will use only mobile apps - android, ios etc.
• they will call backend to operate their request
• the request will be forwarded to the LB
• LB will forward the request to relevant server
• server will call the cache
  • to fetch data
  • if data is not found to write the data into cache
  • REDIS will be used
• backend will be kotlin, spring-boot application
• there will be another component for handling authentication and authorization
• frontend will provide tokens to valide the user in the backend
• database read replicas will be added to reduce the load on the database instances
• Postgres will be used as a database type

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

• lets talk about the server
  • it will get the request and process it
  • it will validate the authentication for each request
  • it will check payment details of a user if they want to access to paid feature
  • based on a load it will have auto-scaling options with max and min replicas

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?