System requirements

Functional:

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

• track a user's activities - number of steps, heart rate, activity type, sleep time, active time, calories burned
• display the activity
• user can set daily goals
• data is available for viewing later also
• data is synced to the cloud and stored in the cloud
• 1 week of data is available on the app.

Non-Functional:

List non-functional requirements for the system...

• accurately track the parameters
• responsive (fast response times)
• memory efficient as it is a mobile app
• secure

Capacity estimation

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

• inputs to the app from monitors and sensors at peak time is ~20 per sec.
• This data is aggregated and written to local storage every ~1 min
• Data size is small ~100KB

So incoming data to the app is ~2MB/second.

Writes to local storage = 2MB per minute = 30 KB per second

Amount of data stored on the cloud will be higher as it contains historical data as well.

API design

Define what APIs are expected from the system...

• Create User

POST https:///user

username:

age:

emailaddress:

phone:

Returns 201 and unique user id

• Edit and delete a user
• Create a goal
• Edit or delete a goal

• View activity

GET https:///activity?type=walking

Response:

{

num hours:

num steps:

calories burned:

distance covered:

approx time:

}

• Same type of query for specific fields such as total number of active hours, total calories burned etc.

• POST and PUT apis for updating the collected metrics in the db.

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

User and Goal Data is structured and can be stored in an SQL DB.

Activity data is unstructured and can be stored using a Metrics DB like InfluxDB or PrometheusDB.

Both type of data stores will be required.

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

1. User creates and account or registers using User Management Service
2. Creates/Edits goals using the Goal Management Service
3. Observer Component collects data from several sources, i.e., HeartRate, Steps, Calories etc.
4. This data is sent to Aggregator for calculating different activity metrics. Periodically, it is written to the local DB and synced with the cloud.

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

1. User creates and account or registers using User Management Service
2. Creates/Edits goals using the Goal Management Service
3. Observer Component collects data from several sources, i.e., HeartRate, Steps, Calories etc.
4. This data is sent to Aggregator for calculating different activity metrics. Periodically, it is written to the local DB and synced with the cloud.

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

• frequence of data aggregation can be adjusted for tradeoff between processing power and accuracy of activity monitoring.

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Bottleneck

===========

• Storing activity data locally on the mobile storage can increase the storage requirement

Failure Scenario

==============

• App Crashing can lead to data loss. Solution: as this data is periodically written to the disk, intermittent app crash will not impact functionality
• User is offline: Backup to cloud can be impacted. To mitigate this, the Aggregator can retry with an exponential backoff.
• Battery Low: Frequency of aggregation, collection and sending data to cloud can be lowered to preserve the battery.

Future improvements

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

Future Improvement:

• Add Friends or Follow feature
• Milestone feature for an achievement
• GPS service

Failure Scenarios Mitigation:

• App Crashing can lead to data loss. Solution: as this data is periodically written to the disk, intermittent app crash will not impact functionality
• User is offline: Backup to cloud can be impacted. To mitigate this, the Aggregator can retry with an exponential backoff.
• Battery Low: Frequency of aggregation, collection and sending data to cloud can be lowered to preserve the battery.