Requirements

Functional Requirements:

Track physical activity:

• What devices and data-sources?
  • wearable (e.g. watch) heart rate sensor?
  • phone accelerometer. Steps, distance walked?
  • manual input? e.g. strength training reps/sets.
• Let's assume we are scoping the problem to just step-tracking and distance moved. The app will focus on walking/running. We'll use the mobile phone as primary input device. We'll support both manual entry and automatic collection of steps (via accelerometer) and distance (via GPS).

Set goals:

• Since focused on steps and distance, we'll base the format of goals around that.
• Set a recurring weekly distance OR step goal.
• Set a workout plan, with weekly goal that increases each week. Plan can be populated from one of a few templates.

Monitor progress:

• Home screen shows current steps today, weekly total, and weekly goal.
• Home screen also shows timeline view of daily steps for last 7 days, with a horizontal bar indicating the goal.

Other:

• Goals, progress, stored on server and sync across devices.
• Supports offline mode (important if in remote location like hiking)

Out of scope:

• social features
• suggest goals to user
• non-phone devices

Non-Functional Requirements:

• Security can be a concern, since using device GPS, and potentially future versions of the app incorporate biometric data. We will not do E2EE, since we want to synch across device. But GPS data will never be sent to server -- only distance derived from it.
• Scale? Assume O(millions) daily active users in different geographical loctions

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

What data is created by the app?

• Steps, distance

// A workout is just a tuple (step_count, distance, start_time, end_time).

// We send these to the server periodically, rather than logging a continuous stream of

// events everytime the device picks up new data.

POST /v1/workouts

body: {

requestId: // for idempotency

start_time: int64

end_time: int64

steps: int

distance: float (meters)

}

// Fetch workout data within a time range. Used to display the current day's progress and

// weekly timeline view. We may want to consider aggregating workouts on the server

// since the app is primarily interested in per-day aggregates, but let's come back to that.

GET /v1/workouts?start_time={}&end_time={}

Response:

[

{

workout_id: 1

start_time: 1234

end_time: 567

steps: 50

distance: 14.5

},

...

]

// Creates a new workout plan. For simplicity, it will just replace the existing one.

// We might support update_workout_plan in the future, so that user can modify their

// plan.

POST v1/create_workout_plan

Body:

{

requestId: // for idempotency

planName: String

startDate: String

weekly_goals: [

{

week: 0,

steps: 20000,

distance: 5000.0,

},

{

week: 1,

steps: 21000,

distance: 5100.0,

},

....

]

}

// Returns the current workout plan, along with workout progress.

GET v1/progress

Response:

{

plan: { .... } // same as above

currentWeek: Int

progress: [

{

week: 0

steps: 19000,

distance 4900,

}

]

}

// A convenience API to return a summary of the current progress, and some user stats.

GET v1/progressSummary

{

currentDayGoal: 5000,

currentWeek: 2

totalWeeksInPlan: 10 // How long is the plan? User can see how close they are to completion

planName: String

currentWeekSteps: [

4000, 3600, // Steps in last 7 days. Most recent first.

]

}

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

Overview

We'll use a layered MVVM architecture, with UI layer being responsible for presentation, a ViewModel layer (ProgressViewModel) that holds UI state, and Model layer (ProgressDataSource) that handles backend and database connections and data integrity.

UI Layer

In this architecture Views are stateless and dumb. Mainly just configure presentation. There are two main screens:

1. Progress View, showing the daily steps and weekly steps.
2. Plan creation screen, where use can set up their plan.

ViewModel

• Holds state required to render the UI. current_steps, goal_steps, last 7 days of steps, etc.
• For plan creation, might hold the current plan details.

Model Layer

• AppDataSource centralizes reads/writes to both offline relational database and oneline backend service.
• Local database is single source of truth. If data not cached locally, read from remote, then both write to local database and return the data to the ViewModel layer.
• GET v1/progressSummary called to populate Progress View. Timeline might be clickable to see details such as longer history of data, which would need to call v1/progress to get full details, possibly also including a pagination token.
• WorkoutTracker, a continuously running component that receives updates from Gps and Accelerometer and converts that into steps + distance. Calls POST v1/workouts
• PlanView, update plan via AppDataSource.

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

Handling high write load and traffic spikes

The nature of this app is write-heavy. It generates a lot of data over time, and only fetches a summary of that data. We need to ensure the write path is set up to scale. A few strategies:

• We don't need to push data to the backend on every step. To keep the app feeling responsive, local DB (or at least the ProgressViewModel) should always keep up-to-date steps, but we only push them to the server after a period of inactivity. For example, if we don't detect steps for 60 seconds we can declare the end of a "workout" and call POST v1/workouts with all the data recorded.
  • tradeoff: some added client complexity to manage state. May need a "status" param on the Workout data structure, which can be "IN_PROGRESS" or "COMPLETE".
• The server can also apply back pressure by returning an error code like "TRY_AGAIN_LATER" to indicate the client should retry the request. Client will maintain a queue of completed workouts, ordered by start time (assume client state ensures they never overlap).
• On the backend, a smart choice of storage stack will help. Key value stores like BigTable can handle high write troughput and are a natural choice for time series. The workout timestamp can be part of the key path, allowing us to query workout progress by time range.
  • tradeoff: not as flexible as relational database. Cannot query by secondary indexes without additional infra and possible denormalization.
• We could also add an in-memory database (Redis) to store recent workout data.

Handling offline/remote merge conflicts

• For the Workout Plan, we will associate a server-generated ID with the plan, and if client version conflicts with server version the server is source of truth. We probably don't need to allow updating the plan when offline anyway.
• Workout progress needs to work offline. Since the timing of a workout is important for historical tracking, we need to let the client assign the timestamp when offline. There could be some wackiness if two clients have vastly different system clocks, but perhaps we don't need to handle that edge case.
• As mentioned in previous section, workout data is queued locally on the client database and pushed to remote at the earliest possible time.

Live access to GPS and Accelerometer

• The app will need to access device sensors while backgrounded. There may be different requirements depending on platform. I'm not sure if it will require the user to explicitly initiate this by taking some action in the app to start a background service. If so, then the UX flow would be to click a button like "start workout".