Fitness activity app (Strava)

01 · CONTEXT

Record, share, and view

The exercise asks for a fitness activity tracking app like Strava: the user records their activities and shares them with their network. The source narrows the focus to running and cycling.

There are three core functional requirements: start, pause, stop, and save a run or ride; see route, distance, and time while the activity is happening; and see the details of one's own completed activities and of friends' activities.

Friend management and authentication and authorization are out of scope. This bounds the design: the case is about recording, storing, and reading activities, not about accounts or relationships between users.

02 · REQUIREMENTS

Four non-functional demands

There are four non-functional requirements: high availability; working in remote areas with no network connection; accurate, up-to-date local statistics during the run or ride; and scale to ten million simultaneous activities.

03 · DESIGN

From the device to storage

The diagram below is an illustrative design by the author, built from the requirements. It shows the write path of an activity and the place of the leaderboard.

1. The athlete's app is where the athlete sees route, distance, and time, and where the local statistics must be available during the activity.

2. When saving the activity, the app sends it through the API entry point to the activity service.

3. The service writes the completed activity to a partitioned store, the starting answer to the scale requirement.

4. In the illustrative design, the service also publishes an event to the queue, so the leaderboard work does not sit inside the save.

5. The consumer updates the leaderboard scoreboard, which is kept in memory to be read quickly.

An activity can be modeled as a set of location and time points, plus summaries such as distance and duration. Separating the summary from the series of points is a decision about data modeling to discuss, and the series of points leads us to think about time-series data.

04 · DEEP DIVES

The source's four questions

The source lists four deep dives: how to record activities offline, how to scale for the load of simultaneous activities, how to share activities with friends in real time, and how to expose a leaderboard of the top athletes.

For offline use, the design has to answer: where the activity is kept on the device; how a resend is recognized as the same activity; and what the server does when it receives the same activity twice.

1. A friend opens the app and asks for the completed activities of the people they follow; the request goes through the load balancer to the read service.

2. The read service tries the cache of recent activities and, if the activity is not there, queries the partitioned store.

3. The leaderboard positions come from the already computed scoreboard, without recalculating on every read.

For the leaderboard, the questions are: what is the cut (global, by friends, or by route segment) and what is the time window. If the cut is by route segment, geospatial indexing comes in, to recognize that an activity passed through the segment; the choice of how to partition the data is another decision to discuss.

05 · LIMITS

What this case does not cover