System requirements

Functional:

1. User Authentication:
   • Users should be able to create accounts, log in, and log out securely.
2. Activity Tracking:
   • Users can log different types of physical activities (e.g., running, walking, cycling) with options for manual entry or GPS tracking.
3. Goal Setting:
   • The app should allow users to set personal fitness goals (e.g., step count, distance, weight loss) and track their progress towards those goals.
4. Progress Monitoring:
   • Display detailed statistics and visualizations of user activities over time, such as calories burned, distance traveled, and milestones achieved.
5. Social Sharing:
   • Users can share their achievements, workouts, or progress with friends or on social media platforms.

Non-Functional:

• System should back up users data to its servers, in case user re-installs the app without saving their local data
• Social sharing features involve generating and serving content from the backend - the app should not serve content to other users.

Capacity estimation

We assuming DAU or 20,000, with each user logging activities once a day on average.

Accounting for spikes in usage, for capacity planning, lets assume all updates show up in the same hour. We have about 10 updates per second, which is well within the capabilities of nearly any NoSQL or SQL database.

We should also size what is needed for the social sharing features. Assuming 10 activities per second being shared with 10 friend each

• Generate 10 HTML pages per second.
• Read QPS of 100 pages per second.

API design

PUT /activity/:activity-id -> Shareable-URL

{

type (e.g. "running")

duration

distance

}

POST /weekly-goal/:goal-id

{

type (e.g. "running")

duration

distance

start_date

end_date

}

GET /activities?start=:starttime&end=:endtime -> Activity[]

Activity {

type

duration

distance

upload-date

}

GET /weekly-goals?start=:starttime&end=:endtime -> Goal[]

Goal {

type (e.g. "running")

duration

distance

start_date

end_date

}

Database design

User

• User-id (primary key)
• name
• email-address

Goal

• goal-id (primary key)
• user-id (secondary index)
• type (e.g. running)
• duration
• distance
• start_date
• end_date
• updatedAt

Activity

• activity-id (primary-key)
• user-id (secondary index)
• type (e.g. running)
• duration
• distance
• upload-date

Use Postgres for storage

High-level design

FrontEnd terminates the connections from client and serves the API. It stores User, Activity and Goal data in Postgres.

In enques content generation requests to the Shared Page Generator.

The Shared page generator generates content that can be shared, and uploads it to blob storage, and puts the URL in Postgres.

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?