Design Strava

• Compliance with data privacy regulations like GDPR.
• Advanced security measures

Strava Non-Functional Requirements

The Set Up

Defining the Core Entities

1. User : Represents a person using the app. Contains profile information and settings.
2. Activity : Represents an individual running or cycling activity. Includes activity type (run/ride), start time, end time, route data (GPS coordinates), distance, and duration.
3. Route : A collection of GPS coordinates recorded during the activity (this could also just be a field on the Activity entity).
4. Friend : Represents a connection between users for sharing activities (note: friend management is out of scope, but the concept is necessary for sharing).

Strava Entities

The API

// Create a new activity
POST /activities -> Activity
{
    type: "RUN" | "RIDE"
}

// Update the state of an activity
PATCH /activities/:activityId -> Activity
{
    state: "STARTED" | "PAUSED" 
}

// Add a new location to the activity's route
POST /activities/:activityId/routes -> Activity
{
    location: GPSCoordinate,
}

// Mark an activity as complete using the same endpoint we use to update the activity state
PATCH /activities/:activityId -> Activity
{
    state: "COMPLETE"
}

// Get a list of activities for a user
GET /activities?mode={USER|FRIENDS}&page={page}&pageSize={pageSize} -> Partial<Activity>[]

// Get an activity by id
GET /activities/:activityId -> Activity

High-Level Design

1) Users should be able to start, pause, stop, and save their runs and rides.

Users should be able to start, pause, stop, and save their runs and rides.

1. Client App : Users interact with the system through a mobile app.
2. Activity Service : Handles incoming requests for creating and updating activities.
3. Database : Stores information about activities, including route, distance, and time.

1. The client app will make a POST request to /activities to create a new activity, specifying whether it's a run or a ride.
2. The Activity Service will create the activity in the database and return the activity object to the client.
3. If the user opts to pause or resume their activity, they'll make a PATCH request to /activities/:activityId with the updated state and the Activity Service will update the activity in the database accordingly.
4. When the activity is over, the user will click the "Save Activity" button. This will trigger a PATCH request to /activities/:activityId with the state set to "COMPLETE".

[
    { status: "STARTED", timestamp: "2021-01-01T00:00:00Z" },
    { status: "PAUSED", timestamp: "2021-01-01T00:10:00Z" },
    { status: "RESUMED", timestamp: "2021-01-01T00:15:00Z" },
    { status: "STOPPED", timestamp: "2021-01-01T00:20:00Z" }
]

2) While running or cycling, users should be able to view activity data, including route, distance, and time.

While running or cycling, users should be able to view activity data, including route, distance, and time.

1. The client app will record the user's GPS coordinates at a constant interval, let's say 2 seconds for a bike ride and 5 seconds for a run. To do this, we'll utilize the built-in location services provided by both iOS and Android:

   • For iOS: We'll use the Core Location framework, specifically the CLLocationManager class. We can set up location updates using startUpdatingLocation() method and implement the locationManager(_:didUpdateLocations:) delegate method to receive location updates.
   • For Android: We'll use the Google Location Services API, part of Google Play Services. We can use the FusedLocationProviderClient class and call requestLocationUpdates() method to receive periodic location updates.
2. The client app will then send these new coordinates to our /activities/:activityId endpoint.
3. The Activity Service will update the Route table in the database for this activity with the new coordinates and the time the coordinates were recorded.
4. We will also update the distance field by calculating the distance between the new coordinate and the previous one using the Haversine formula.

3) Users should be able to view details about their own completed activities as well as the activities of their friends.

-- For mode = USER
SELECT * FROM activities 
WHERE state = "COMPLETE"
AND userId = :userId
LIMIT :pageSize OFFSET (:page - 1) * :pageSize

-- For mode = FRIENDS
SELECT * FROM activities 
WHERE state = "COMPLETE"
AND userId IN (SELECT friendId FROM friends WHERE userId = :userId)
LIMIT :pageSize OFFSET (:page - 1) * :pageSize

Users should be able to view details about their own completed activities as well as the activities of their friends.

1. User navigates to the activities list page on the app.
2. Client makes a GET request to /activities?mode={USER|FRIENDS}&page={page}&pageSize={pageSize} to get the list of activities.
3. The list of activities is rendered in the UI and the user clicks on an activity to view details.
4. Client makes a GET request to /activities/:activityId to get the full activity details to render on a new details page.

Potential Deep Dives

1) How can we support tracking activities while offline?

1. We can track activities without worrying about network reliability on the client side.
2. Even when the client has a fine network connection, we save network bandwidth by avoiding pinging location updates to the server every few seconds (instead, only sending on run completion or pause).
3. Showing accurate and up-to-date activity data to the user is easy as it all happens synchronously on their device.

1. Just like in our high-level design, we use on-device location services to record the user's GPS coordinates at a constant interval.
2. We record this event data locally on the device in an in-memory buffer (e.g., an array of GPS coordinate and timestamp pairs).
3. To prevent data loss in case of device shutdown or battery depletion, we'll periodically persist this buffer to the device's local storage every ~10 seconds:

   • For iOS: We can use Core Data for larger, structured datasets, or UserDefaults for smaller amounts of simple key-value data.
   • For Android: We can use Room database for larger, structured datasets, or SharedPreferences for smaller amounts of simple key-value data.
4. When the app is reopened or the activity is resumed, we first check local storage for any saved data and load it into our in-memory buffer before continuing to record new data.
5. Once the activity is complete and the device is online, we send all the accumulated data to our server in a single request. For very long activities, we might need to implement a chunking strategy to handle large amounts of data efficiently.
6. We can also implement a background sync mechanism that attempts to upload data periodically when a connection becomes available, even if the activity isn't complete yet. This balances efficiency with data durability.
7. Upon confirmation that the data was saved to our remote database, we can delete the local buffer and are ready to go again.

How can we support tracking activities while offline?

2) How can we scale to support 10 million concurrent activities?

• Basic metadata like status, userID, start/end time, etc should be pretty cheap. Let's say ~100 bytes per activity.
• The route is the most expensive part. If the average activity is 30 minutes and we take GPS coordinates, on average, every ~3 seconds, then we'll have about 600 points per activity. Each route row needs a latitude and longitude field as well as a timestamp. This is an additional (8bytes + 8bytes + 8bytes) * 600 = ~15KB .

1. We can shard our database to split the data across multiple database instances. We can shard by the time that the activity was completed since the majority of our queries will want to see recent activities.
2. We could introduce data tiering. The chances that someone wants to view a run from several years ago are pretty low. To reduce storage costs, we could move older data to cheaper storage tiers:

   • Hot data (recent activities) stays in fast, expensive storage
   • Warm data (3-12 months old) moves to slower, cheaper storage
   • Cold data (>1 year old) moves to archival storage like S3
3. We can introduce caching if needed. If we find that we are frequently querying the same activities, we can introduce caching to reduce the read load on our database. This would not be a priority for me, as read throughput should be pretty low. but its the first thing we would do if load times become unacceptable.

How can we scale to support 10 million concurrent activities?

3) How can we support realtime sharing of activities with friends?

1. Updates are predictable: Unlike with Messenger or Live Comments, we know that the next update should come in the next 2-5 seconds. This predictability allows for efficient polling intervals.
2. Real-time precision isn't critical: Friends don't need to see up-to-the-second information. A slight delay of a few seconds is acceptable and won't significantly impact the user experience.

4) How can we expose a leaderboard of top athletes?

Bad Solution: Naive Approach

Approach

The simplest thing we can do is to query the DB for all activities and then group them by user and sum the distance. We can assume we have some user table with basic information like name, email, country, etc.

This would look something like this:

SELECT
    u.name,
    SUM(a.distance) as total_distance
FROM activities a
JOIN users u ON a.userId = u.userId
WHERE a.state = "COMPLETE"
AND a.type = "RUN"
GROUP BY u.userId
ORDER BY total_distance DESC

Naturally, this query will be pretty slow given it is running an aggregation over millions of activities. There are several ways we can optimize this.

Challenges

This approach faces significant scalability issues. As the number of activities increases, query performance will degrade rapidly. The system would need to scan and aggregate millions of records for each leaderboard request, leading to high latency and increased database load. Additionally, this method doesn't account for the dynamic nature of leaderboards, where rankings can change frequently as new activities are logged.

Good Solution: Periodic Aggregation

Approach

To improve on the naive approach, we can implement a periodic aggregation system. This involves creating a separate leaderboard table that stores pre-calculated totals for each user. A background job would run at regular intervals (e.g., daily) to update these aggregates based on new activities. The leaderboard query then becomes a simple SELECT from this pre-aggregated table, sorted by total distance.

Periodic Aggregation

Challenges

While this method significantly reduces query time for leaderboard requests, it introduces eventual consistency. The leaderboard won't reflect real-time changes, potentially leading to user confusion if their latest activity isn't immediately reflected in their ranking. In addition, determining the optimal frequency for updates can be tricky – too frequent updates could strain system resources, while infrequent updates lead to stale data.

Great Solution: Real-time Leaderboard with Redis

Approach

For a more scalable and real-time solution, we can leverage Redis , an in-memory data structure store. We'll use Redis Sorted Sets to maintain leaderboards, with user IDs as members and their total distances as scores. When a new activity is logged, we increment the user's score in the sorted set. To query the leaderboard, we simply retrieve the top N members from the sorted set, which Redis can do extremely efficiently.

What happens when we want to filter by country or time range?

To handle filtering by country or time range, we can extend our Redis-based approach:

1. For country filtering:

   • We can create separate sorted sets for each country, e.g., "leaderboard:run:USA", "leaderboard:run:Canada", etc.
   • When an activity is logged, we update both the global leaderboard and the country-specific leaderboard.
   • To query a country-specific leaderboard, we simply use the appropriate country-specific sorted set.

# Add an activity to the leaderboard (increment user's total distance)
redis.zincrby(f"leaderboard:run:global", distance, user_id)
redis.zincrby(f"leaderboard:run:USA", distance, user_id)

# Query the leaderboard (get top users by total distance)
redis.zrange(f"leaderboard:run:global", 0, -1, desc=True, withscores=True)

1. For time range filtering, we have a more sophisticated approach that combines both sorted sets and hashes:

   • We'll use a combination of Redis sorted sets and hashes to store both timestamp and distance information.
   • For each activity, we'll store:

     1. A sorted set entry with the activity ID as the member and timestamp as the score.
     2. A hash entry with the activity ID as the key, containing fields for user ID and distance.
   • When querying the leaderboard for a specific time range:

     1. Use ZRANGEBYSCORE to get activity IDs within the desired time range.
     2. For these activity IDs, retrieve the corresponding user IDs and distances from the hash.
     3. Aggregate the distances by user ID in-memory.
     4. Sort the aggregated results to produce the final leaderboard.

Here's a pseudo-code example of how this might work:

# When logging a new activity
activity_id = generate_unique_id()
redis.zadd("activities:timestamps", {activity_id: timestamp})
redis.hset(f"activity:{activity_id}", mapping={"user_id": user_id, "distance": distance})

# Querying the leaderboard for last 24 hours
now = current_timestamp()
day_ago = now - 24*60*60
activity_ids = redis.zrangebyscore("activities:timestamps", day_ago, now)

user_distances = {}
for activity_id in activity_ids:
    activity_data = redis.hgetall(f"activity:{activity_id}")
    user_id = activity_data["user_id"]
    distance = float(activity_data["distance"])
    user_distances[user_id] = user_distances.get(user_id, 0) + distance

# Sort users by total distance
leaderboard = sorted(user_distances.items(), key=lambda x: x[1], reverse=True)

This approach allows us to efficiently filter by time range and aggregate distances, providing a real-time leaderboard that can be customized for different time periods. We can cache the results with a short TTL to limit the in-memory aggregation while still ensuring freshness.

Strava System Design

Challenges

The main challenge with this approach is ensuring data consistency between Redis and our primary database. We need to implement a robust system to handle failures and retries when updating Redis. Additionally, we must consider Redis's memory limitations – storing complete leaderboard data for all possible combinations of activity types, time ranges, and geographical filters could consume significant memory. To mitigate this, we might need to implement a caching strategy where we only keep the most frequently accessed leaderboards in Redis and calculate less common ones on-demand.