System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

• standalone mobile phone app without accessories.
• (optional) support accessories such as watches via wireless connections.
• the app should be able to record the start/stop/resume of a set of predefined physical activities, such as walking, running.
• (optional) the app can detect activities such as running and suggest users to start tracking.
• the app should be able to allow users to set goals and display a UI to show the progress.
• multi-device support: Web, mobile app.
• authentications: only users themselves can see the data.
• users should be able to delete data from device and cloud at any time.

Non-Functional:

List non-functional requirements for the system...

• latency: data should be synced to multiple devices with minimum latency.
• security: only users themselves can see the data.

Capacity estimation

Estimate the scale of the system you are going to design...

• Clould storage and requests: assume we have 100M DAU, each user would have 1 activity per day to add, and navigate the past activities in the past 7 days.
• Storage: each activity could include several meta data fields, let's assume 100KB data. Total data volume per day: 100M * 100KB = 10000GB = 10TB. Say we have a data retention for 30d, the total storage would be 10TB * 30 = 300TB. Each user could have multiple goals, but the total number would be much less than activities. Say the ratio is 1:10 for goals:activities, the storage for goals would be another 30TB.
• Write requests (add activity entries): 100M per day, assume global usage and evenly distributed, so 100M/100K = 1K request per second.
• Read requests (navigate past activities): 1K * 10 = 10K per second.

API design

Define what APIs are expected from the system...

We need two APIs: one for read past activities and goals, another for create/delete/update activities and goals.

• read past activities and goals: this API would return past activities in certain time range.
• CRUD activities/goals: this API would mutate actitives and goals data.

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

data model:

• user: <user_id, name, account, ...>
• activity: <activity_id, user_id, name, label, activity, time_stamp>. name could be running/walking, label could be accociated tags such as outdoor, etc, activity can be start/pause/stop/resume.
• goal: a goal could be associated with an activity, or a type of activity (outdoor), with certain time range. Status of a goal could be not_started/in_progress_abandoned/achieved/etc.
• <goal_id, name, activity_name, activity_label, start_time, end_time, status>

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

the system would include several component:

1. an API gateway that can do a few things:
2. user autentication.
3. load balancing of user requests and dispatch user requests of either read or write to a server to process.
4. an past_activities service that read past activities and goal statuses and return that to the client.
5. an service that can handle create, delete, and update activities.
6. databases for users, activites and goal statuses.

diagram:

flowchart TD

A[Mobile App] -->|API Requests| B[Server]

C[Web Portal] -->|API Requests| B

D[Wearable Devices] -->|Data Sync| B

B --> E[Database]

B -->|Real-Time Data| F[Notification Service]

F --> A

F --> C

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...

add/delete/update an activity:

1. users can start/update/delete an activity via a client (the mobile app).
2. the entry is stored locally and also would synced to cloud via a secure connection. (say https)
3. the cloud service will have an API gateway that distribute this request to a server that process and store this data.
4. the data will be stored in the activities and goals databases.

sync new activity data (pull-based):

1. a client connects to the cloud service with authentications
2. if the loggin success, pull the activities and goals data from server via an API (graphQL for example)
3. display the goals, activities, and statues based on the latest data.

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...

the two most critical components are 1) activities_reads and 2) activities_CRUD

• activities_reads
• 
  

• activities_CRUD
• 
  

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.

Authentication Failures:

Networking failures:

Future improvements

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

Connection with accessories (like fitness band). Usually Bluetooth connections are used for this.

Offline modes: activities data should be saved in client db like sqllite.