System Design: Strava (Walnut Run: GPS Tracks, Segment Matching, Leaderboards for 200M Athletes)
Goal: Design our own fitness tracking service, like Strava. We call it Walnut Run. Runners and cyclists record activities with GPS. We work out distance, time and climb, compare each route with stretches of road that people have marked, and rank everyone's times.
We plan for 200 million athletes and 6 million uploads a day, with spikes of 1,000 uploads a second.
1. What We Are Building
🔒 Premium section
2. Requirements and Scale
2.1 What the System Must Do
Two words first. KOM and QOM (King and Queen of the Mountain) mean first place on a segment's leaderboard, for men and for women. A Local Legend is the athlete with the most efforts on a segment in the last 90 days. Each FR (functional requirement) is something the system must do.
| ID | Requirement |
|---|---|
| FR-01 | Record runs, rides, walks and hikes with GPS on the phone, even with no signal. |
| FR-02 | Accept FIT, GPX and TCX files, the common GPS file formats (also compressed with gzip, a common way to make files smaller), from watches and bike computers, sent by their makers' services. |
| FR-03 | Show distance, elapsed and moving time, pace, climb and splits (time per km or mile). |
| FR-04 | Show the route on a map, plus heart rate, cadence and power when recorded. |
| FR-05 | Let athletes create a segment from part of a past activity. |
| FR-06 | Find every segment an activity passes and record an effort for each pass, laps included. |
| FR-07 | Leaderboards: top 10 for everyone; full board and filters (gender, year, month, age, weight, people you follow, club) for subscribers (paying members); KOM, QOM and Local Legend. |
| FR-08 | Follow athletes, see a feed, give kudos, comment, get notifications. |
| FR-09 | Choose who sees each activity. Hide the start and end of maps. Offer privacy zones. |
| FR-10 | Share live location with up to 3 safety contacts. |
| FR-11 | Build a public heatmap that shows where many people run and ride. |
| FR-12 | Flag a bad effort or a dangerous segment. |
| FR-13 | Export original files and delete the account. |
2.2 How Well It Must Do It
p50 is the time that half of all requests beat. p99 is the time that 99 of every 100 beat, so it shows the slow tail. An SLO (service level objective) is a target we set and measure each month. Each NFR (non-functional requirement) says how well the system must work.
- NFR-01. Upload accepted. File stored and answer sent within 1 s at p99. An accepted file is never lost, short of losing a whole region for good (section 17.4).
- NFR-02. Activity ready. Stats and map, with privacy applied, within 2 s at p50 and 10 s at p99 at normal load. Strava's published mean is under 2 seconds (Strava API docs, 2026), so users expect this.
- NFR-03. Efforts and feed. Leaderboards updated within 60 s at p99, followers' feeds within 30 s. Some efforts are held back for a fair-play check or a review before they go public. This target does not count them (section 10).
- NFR-04. Spikes. Accept 1,000 uploads a second. In a spike, "ready" may slip to minutes. Background batch jobs, which run over old data, slip first. Then efforts and leaderboards, then feeds, and stats last.
- NFR-05. Availability. Upload accept 99.95% a month (about 22 minutes of failure). Reads 99.9% (about 43 minutes).
- NFR-06. Fair and private. A noisy effort stays off public boards until reviewed. An impossible effort never reaches a public top 10. A hidden part of a track never appears in any output.
- NFR-07. Data stays home. An athlete's files and activities stay in their home region (US, EU or Asia-Pacific).
2.3 The Numbers
These are our planning numbers. Section 16 has the full math.
Athletes. 200 million registered, close to Strava's 195 million (2026).
Uploads. 6 million activities a day, which is 42 million a week, close to Strava's 40 million.
- Average. 6,000,000 / 86,400 seconds is about 70 a second.
- Evening peak. 5 times that, about 350 a second.
- Event spike. New Year's Day, a race morning, the return after an outage. 10 times, about 700 a second.
- Design target. 1,000 a second: the spike plus draining uploads that queued during an outage.
GPS points. A GPS point is one position reading (section 3). The average activity lasts 1 hour, so at 1 point a second it has 3,600 points. That is 21.6 billion points a day, about 250,000 a second. So we never store one database row per point (section 5.1).
Efforts. 10 per activity on average: 60 million a day, about 700 a second, 7,000 a second at the spike.
Leaderboard writes. Each cached segment has 4 boards: all-time, all-time for the athlete's gender, this year and this month. So one effort updates up to 4 boards: 28,000 writes a second at the spike.
Feed, kudos, live tracking.
- Feed. 50 followers per athlete on average (our number). Copying each activity to each follower is 300 million writes a day, about 3,500 a second, 35,000 at the spike.
- Kudos. 14 billion a year, Strava's 2025 level. About 450 a second, 4,500 at a spike.
- Live tracking. 500,000 sessions at the peak, one location each 15 seconds: about 33,000 writes a second.
Storage. We keep three forms of each activity: the original file (about 100 KB, kept forever), a clean track (about 10 KB) and a map line (about 1 KB). The first two go to object storage: about 242 TB a year, almost all original files. Map lines add about 2.2 TB a year to the database (sections 7.10 and 16.3).
Segments. 40 million, with 20,000 new ones a day.
2.4 Out of Scope
- Route planning. Drawing a route before you go is a separate product.
- Training plans and fitness scores. They read our data but don't change the core design.
- Payments. We only ask "is this athlete a subscriber?" before showing a full leaderboard.
- Map matching for navigation. Map matching snaps a track onto known roads, which turn-by-turn directions need. We give no directions. Section 8 compares it with our segment check.
3. How GPS Tracks Work
🔒 Premium section
4. The API and Data
🔒 Premium section
5. High-Level Design
🔒 Premium section
6. Deep Dive: Upload and the Processing Pipeline
🔒 Premium section
7. Deep Dive: Cleaning the Track
🔒 Premium section
8. Deep Dive: Segment Matching
🔒 Premium section
9. Deep Dive: Leaderboards
🔒 Premium section
10. Deep Dive: Fair Play
🔒 Premium section
11. Deep Dive: Privacy Zones
🔒 Premium section
12. Deep Dive: Social Feed, Kudos and Comments
🔒 Premium section
13. Deep Dive: Heatmaps
🔒 Premium section
14. Deep Dive: Live Tracking
🔒 Premium section
15. Deep Dive: Spikes and Backlogs
🔒 Premium section
16. Capacity
🔒 Premium section
17. What Happens When Each Part Goes Down
🔒 Premium section
18. Bottlenecks
🔒 Premium section
19. Regions and Data
🔒 Premium section
20. Security and Abuse
🔒 Premium section
21. Running It
🔒 Premium section
22. Trade-offs
🔒 Premium section
23. In the Interview
🔒 Premium section
24. How We Measured
🔒 Premium section
25. Further Reading
🔒 Premium section
Explore the Technologies
🔒 Premium section