Design Strava (Fitness Tracking & Segment Leaderboards)
Design Strava (Fitness Tracking & Segment Leaderboards)
Strava processes millions of high-frequency GPS activity streams uploaded by athletes, automatically detecting when a user traversed a designated "Segment" (e.g. a steep hill climb) and updating competitive global leaderboards.
1. System Requirements
Functional Requirements
- Activity Recording & Upload: Ingest GPX / FIT files containing timestamped latitude, longitude, elevation, and heart rate telemetry.
- Segment Matching: Automatically detect if any portion of an activity polyline matches a crowdsourced segment.
- Real-time Leaderboards: Rank the fastest all-time efforts (KOM/QOM) on any segment with instant updates.
- Activity Feed & Kudos: Social feed showing friends' recent workouts.
Non-Functional Requirements
- High Ingestion Throughput: Process bursty uploads on Sunday mornings without backlog.
- Accurate Map Matching: Resilient against noisy GPS drift and signal drops under tree cover.
- Sub-Second Leaderboard Reads: Leaderboard queries must return in $< 50\text{ms}$.
2. Segment Detection Algorithm: Spatial Bounding & Polyline Frechet Distance
- Bounding Box Filter: Every segment has an entry bounding box and exit bounding box indexed by Geohash. If an activity doesn't intersect both, it's discarded immediately.
- Frechet / Hausdorff Distance: Measures similarity between the candidate GPS trajectory and the canonical segment path.
- Time Calculation: Interpolate exact timestamps at the start and finish lines to record elapsed time down to the hundredth of a second.
Key Architecture Trade-Offs & Decision Matrix
| Decision Factor | Choice A | Choice B | Selected Architectural Rationale |
|---|---|---|---|
| Communication Protocol | REST over HTTP/2 | WebSockets / gRPC | Use REST for stateless CRUD APIs; use WebSockets for low-latency bidirectional streaming. |
| State Management | Centralized Distributed Store | Local Memory with Sticky Sessions | Centralized Redis / Database state allows seamless container auto-scaling and zero-downtime rolling deploys. |
| Concurrency Control | Optimistic Locking (version column) | Pessimistic Locking (SELECT FOR UPDATE) | Optimistic locking delivers superior throughput for low-conflict consumer operations. |
Related Topics
Expand your knowledge by learning about adjacent concepts in system design.
Design a URL Shortener (TinyURL / Bitly Architecture)
Design a scalable URL shortening service capable of handling billions of redirects: Base62 encoding, distributed ID generation, database indexing, and 301 vs 302 redirect trade-offs.
Design Bitly (Scalable URL Shortener & Analytics Platform)
Design a high-scale URL shortening and click tracking service like Bitly or TinyURL capable of handling billions of redirects with sub-15ms latency.
Dropbox
System design answer key for designing a file storage and synchronization service like Dropbox, built by FAANG managers and staff engineers.
Cheat Sheet Utility
View and print a concise system design reference card.