System requirements

Functional:

• Track physical activities
• Set Goals
• Monitor Progress

Non-Functional:

• Available -> Minimize App downtime
• Scalable -> Multiple Users

Capacity estimation

• Assuming ~5000000 daily users
• On average tracking 3 tasks a day
• 
  

API design

External:

• GET /info
• Get user's info -> needs userID, fetches the progress of activities

• GET /goals
• Get the information from Goal Table

• POST /setGoals
• Set or update user goals -> needs userID, update the goals

Database design

Users Table (SQL)

• First Name
• Last Name
• Birthdate
• Phone number
• UserID

Activity Table (NoSQL)

• UserID
• Activities
• ActivityID
• ActivityName
• TimeStampStart
• TimeStampEnd

Goal Table (NoSQL)

• UserID
• ActivityID
• Number of times completed
• Target of times completed

High-level design

First the user would send a request to our serverside

This request will go through a load balancer to prevent overwhelming any single server

/info endpoint will grab the users progress for all activities

/setGoals endpoint will update the user's goals, either add new goal or update the progress of an existing goal

We'd probably want a cache to keep track of the activities the user has done, the user may go to check the recent activities they've multiple times

The reason for the app is because the user doesnt remember every activity so it's likely the user is using the app to see what they did

Let's say for every write theres 2 reads -> Read heavy

Because we're it may be a good idea to -> Async replicas

Shard database to handle concurrent writes to database

-> shard by region -> shard the shard if we need to

Request flows

Client -> Load Balancer -> server

• POST -> update DB -> update Cache -> Send result to clientside
• GET /info -> Check Cache
• -> Cache Miss -> Check DB -> send to Client
• -> Cache Hit -> Send to client
• GET /goal-> Check Cache
• -> Cache Miss -> Check DB -> send to Client
• -> Cache Hit -> Send to client

Detailed component design

• /info will query DB for document for all of the activies that the user has done
• /setGoals will update user's activity for when he/she completed activity, will also increase the count of the goal if goal is set

Trade offs/Tech choices

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

Failure scenarios/bottlenecks

Bottle necks may be if too many users try to update at the same time, but that is why we chose to shard the DB

Future improvements

Possibly new feature requests depending on what the client is looking for when using the app