System requirements

Functional:

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

• Users can sign up to track their fitness data; their information can be persisted to the cloud
• Fitness data is:
• tracking numeric data about biometrics and reps
• Include longform notes and descriptions
• Information is populated from fitness devices
• Graphs, charts are to be populated
• Notifs for reminders

Non-Functional:

List non-functional requirements for the system...

• Consistency: Since there will be multiple devices that could be paired with this app, we should expect consistency between devices. It would be very frustrating to enter data for one metric only for it to be accidentally erased by logging onto another device.
• Availability: It depends on what the metric is, as some metrics would need more availability than others. For example, if we're tracking steps, then it would have to be very available to track every step. But another feature, like tracking "how much time was spent weightlifting," would require just putting down a number once.
• Persistence: The user should expect that the data gets saved to the cloud for years to come. People often want to know what their progress is over the course of years, not just months or weeks.
• Scalability: Let's say the app is expected to have a user base of 100,000 users. But, not everyone who downloads the app is going to use it. Let's say just over half uses it, or 60%. If every day there are on average, 10 requests sent from every user, then we will need to handle 600,000 requests a day.
• Security: Biometrics might require more security than the average app. When users authenticate signing up or accessing their, we could implement face ID or SSO with other trusted authentication platforms. We should also think about how the data is stored on the cloud (using cryptographic hashes for example) and appropriately provision permissions for certain parties to be able to access or see it, for data security/privacy.

Capacity estimation

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

Let's say the app is expected to have a user base of 100,000 users. But, not everyone who downloads the app is going to use it. Let's say just over half uses it, or 60%. If every day there are on average, 10 requests sent from every user, then we will need to handle 600,000 requests a day.

API design

Define what APIs are expected from the system...

• createUser()
• startTrackingFitnessGoal(userId) -> FitnessDataID
• trackFitnessDatum(userId, fitnessDataID)
• viewCharts(userId) -> ChartId

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

users

userId

... (things like name, etc.)

password (cryptographically hashed)

devices

deviceId

userId

deviceEnum

fitnessGoal

fitnessGoalId

fitnessEnum

userId

fitnessDatum

fitnessDatumId

fitnessGoalId

deviceId

value

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

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?