Design a Fitness Tracking Service (Strava / MapMyRun)

TL;DR. A fitness tracking service ingests GPS traces from 195M+ athletes^[1], matches each activity against tens of millions of user-created segments via a two-stage pipeline (H3 pre-filter then DTW refinement), and maintains per-segment leaderboards backed by Kafka event streams and Redis sorted sets^[2]. The pivotal trade-off: server-side segment matching is expensive (1B matches/day) but mandatory for anti-cheat, since client-side detection is trivially spoofable. The 2018 heatmap incident, which exposed covert military bases from opt-in-by-default location data^[3], proves that privacy must be a design input, not a toggle.

Learning Objectives#

• Design a GPS ingestion pipeline handling 16 TB/day of time-series points plus a live-stream sidechannel
• Implement segment matching as a two-stage pipeline: geospatial pre-filter (H3 cells) then DTW refinement
• Compare live-during-ride leaderboards against batch post-activity reconciliation and justify the premium-tier split
• Generate privacy-respecting heatmaps at planetary scale using Spark batch with k-anonymity thresholds
• Reason about anti-cheat (GPS spoofing, wrong-sport uploads) as a first-class requirement that removed 14.85M activities across 2024-2026^[4]

Intuition#

Recording a bike ride looks like a trivial CRUD app. Accept a GPS file, store it, show a map. A single PostgreSQL table handles 10 users fine.

At 195 million athletes uploading tens of millions of activities per day (as of 2025)^[4:1], three pressures break the naive design. First, every upload must be compared against tens of millions of segments to find which ones the athlete crossed. Without a pre-filter, that is 10^14 comparisons per day. Second, the leaderboard for each segment must update within seconds so a rider finishing a climb sees their rank immediately. Third, aggregating all that GPS data into a global heatmap exposed military patrol routes in 2018 because nobody asked "what happens when we visualize opt-in-by-default data from war zones?"

The insight that unlocks the design: decompose segment matching into a cheap spatial pre-filter (H3 cells reduce candidates from millions to roughly 100) followed by an expensive precise matcher (DTW handles jitter and different sample rates). This two-stage pattern keeps CPU cost bounded as the segment library grows, and it runs server-side so cheaters cannot bypass it.

Requirements#

Clarifying Questions#

• Q: Live segment feedback during the ride, or only after upload? Assume: Both. Live Segments is a premium feature; post-activity matching is the free-tier default.^[5]
• Q: What file formats must we support? Assume: FIT (Garmin/Wahoo binary, the industry standard), GPX (open XML), and TCX (Garmin Training Center XML).^[6]
• Q: Privacy controls? Assume: Privacy zones (configurable radius around home/work), per-activity visibility, heatmap opt-out, and k-anonymity thresholds.^[7]
• Q: Integration with third-party platforms? Assume: OAuth 2.0 API with webhooks for activity create/update/delete events; integrations with Garmin Connect, Apple HealthKit, Peloton, Zwift.^[8]
• Q: Anti-cheat requirements? Assume: Server-side detection of GPS spoofing, wrong-sport uploads (e-bike as bike, car as run), and historical backfill of leaderboards on model upgrades.^[4:2]
• Q: Subscription model? Assume: Free tier (post-activity matching, basic stats) and premium tier ($79.99/yr) with Live Segments, training analytics, and Beacon.^[9]

Functional Requirements#

• Upload activity (FIT/GPX/TCX) with metadata; return activity_id after async processing (mean < 2 seconds)^[6:1]
• Match activity against global segment library; compute elapsed time per matched segment
• Maintain per-segment leaderboards across timeframes (all-time, year, month) with KOM/QOM rankings
• Generate a global heatmap from aggregated, anonymized activity data
• Stream real-time GPS during an activity for Live Segments and Beacon (location sharing with 3 contacts)
• Social layer: follower feed, kudos, comments, clubs, challenges

Non-Functional Requirements#

• Load: 10M activities/day (~115 uploads/sec average, 500/sec peak); 100K concurrent live-trackers
• Latency: Upload-to-visible p99 < 30 s; segment match p99 < 5 s; leaderboard update < 5 s end-to-end
• Availability: 99.9% write path; 99.95% read path
• Durability: 99.999% for activities (irreplaceable personal data)
• Consistency: Eventual for leaderboards (seconds of staleness acceptable); strong for activity writes

Capacity Estimation#

• Read:write ratio: Leaderboard reads dominate at ~100:1 over writes. Activity uploads are write-heavy but moderate QPS (~115/sec average).
• Compression: A 1-hour ride produces ~100 KB raw; FIT binary compresses to ~10 KB.^[6:2]
• Bandwidth: Live tracking: 100K concurrent x 1 pt/s x 16 B = 1.6 MB/s inbound (trivial).

API and Data Model#

API Design#

POST /v1/uploads
  Content-Type: multipart/form-data
  Body: { file: <FIT/GPX/TCX>, activity_type: "ride", name: "Morning Ride" }
  Returns: 202 { "upload_id": "abc123", "status": "processing" }
  Poll: GET /v1/uploads/{upload_id} until activity_id is populated

GET /v1/activities/{id}
  Returns: 200 { "id": "...", "distance_m": 42195, "moving_time_s": 3600,
                  "polyline": "<encoded>", "segment_efforts": [...] }

GET /v1/segments/{id}/leaderboard?timeframe=year&page=1
  Returns: 200 { "efforts": [{"athlete_id": "...", "elapsed_s": 124, "rank": 1}],
                  "next_cursor": "..." }

POST /v1/segments
  Body: { "name": "Hawk Hill Climb", "polyline": "<encoded>", "sport_type": "ride" }
  Returns: 201 { "segment_id": "seg_789" }

WebSocket /v1/live/stream
  Client sends: { "lat": 37.77, "lng": -122.41, "alt": 50, "ts": "..." } at 1 Hz
  Server pushes: { "segment_entered": "seg_789", "delta_vs_pr": -3.2 }

Data Model#

-- Activity metadata (PostgreSQL, sharded by user_id)
CREATE TABLE activities (
  activity_id   BIGINT PRIMARY KEY,
  user_id       BIGINT NOT NULL,
  sport_type    TEXT,
  start_time    TIMESTAMPTZ,
  distance_m    INT,
  moving_time_s INT,
  elevation_m   INT,
  device_type   TEXT
);

-- GPS points (time-series store / Parquet on S3, partitioned by month)
-- Schema: (activity_id, ts, lat, lon, alt, hr, cadence, power)
-- Hot tier: last 90 days in columnar TSDB
-- Cold tier: Parquet on S3, queryable via Spark

-- Segments (PostgreSQL + PostGIS for spatial queries)
CREATE TABLE segments (
  segment_id  BIGINT PRIMARY KEY,
  polyline    GEOMETRY(LineString, 4326),
  h3_cells    BIGINT[],  -- pre-computed H3 res-11 cells covering the segment
  sport_type  TEXT,
  min_length_m INT CHECK (min_length_m >= 250)
);
CREATE INDEX ON segments USING GIN (h3_cells);

-- Leaderboard efforts (Redis sorted sets)
-- Key: seg:{segment_id}:{timeframe}:{sport}
-- Score: elapsed_ms  Member: athlete_id
-- One ZSET per (segment, timeframe) tuple

High-Level Architecture#

The upload path stores raw files in S3 and hot GPS in a TSDB, then Kafka fans out to the activity processor, segment matcher, feed, and notifications; the heatmap runs as a monthly Spark batch over the cold Parquet tier.

Write path: The mobile client POSTs a FIT/GPX file to the Upload Service. The service validates the payload, stores the raw file in S3, normalizes GPS points into the hot TSDB, and publishes an activity.created event to Kafka. The Activity Processor consumes this event, computes stats (distance, pace splits, elevation gain), and enqueues a segment-match job.

Read path: Leaderboard queries hit Redis sorted sets directly. Activity detail queries join PostgreSQL metadata with a downsampled polyline (Ramer-Douglas-Peucker to ~1K points for rendering). The feed service pushes activity events to follower inboxes.

Live path: During a ride, the phone streams 1 Hz GPS over a WebSocket to the Live Stream Service. This service projects the stream onto nearby segment polylines and pushes real-time pace deltas back to the device.

Deep Dives#

Segment matching: the two-stage pipeline#

The segment library contains tens of millions of user-created segments globally. Matching every upload against every segment is computationally impossible. The solution is a two-stage pipeline.

Stage 1: H3 spatial pre-filter. When a segment is created, we pre-compute its H3 cells at resolution 11 (~0.002 km^2 per cell, ~29 m average edge length) and store them in a GIN-indexed array column.^[11] When an activity arrives, we compute the H3 cells the activity traverses and query for segments whose h3_cells array overlaps. This reduces candidates from tens of millions to roughly 100 per activity.^[12]

Stage 2: Precise matching with DTW. For each candidate segment, we run Dynamic Time Warping (DTW) between the activity's sub-polyline and the segment's reference polyline.^[13] DTW handles different recording intervals (1 Hz vs 5 Hz devices) and minor GPS jitter while producing a scalar distance metric. We additionally check direction of travel by comparing the start-to-end traversal vector, and enforce a buffer zone tolerance for GPS drift at the start and end lines.^[12:1]

H3 pre-filter cuts the candidate set from tens of millions to ~100; the precise stage runs direction-checked DTW and writes matched efforts to the leaderboard.

Why not client-side matching? Client-side detection has zero backend fanout but is trivially spoofable. Strava's anti-cheat pipeline removed 14.85M anomalous activities across 2024-2026 backfills^[4:3], which would be impossible if matching ran on untrusted clients.

Minimum segment lengths: Segments shorter than 500 m (ride) or 250 m (run) have a GPS noise floor comparable to their length, making elapsed-time computation unreliable. Strava no longer allows creation below these thresholds.^[4:4]

Heatmap generation and the 2018 privacy incident#

The global heatmap visualizes where athletes run and ride by aggregating GPS density into raster tiles. The 2017 rebuild processed 700 million activities, 1.4 trillion lat/lon points, and 5 TB of raw input using Apache Spark and Scala.^[10:1]

The incident: In January 2018, an Australian student noticed that the heatmap revealed patrol routes, perimeters, and supply routes at covert military bases in Syria, Afghanistan, and Djibouti. The UK Ministry of Defence assessed it as "a clear risk" and reissued internal cyber-security guidance.^[3:1][14] The root cause: opt-in-by-default location data from military personnel in low-density areas lit up because even a handful of regular users trace a perimeter.

The fix (March 2018): Opt-out enabled, login required for street-level data, monthly rebuild cadence so privacy changes propagate within a month, configurable privacy zones around home/work, and a k-anonymity threshold requiring "several different athletes" per cell before rendering.^[7:1]

Privacy filters apply before aggregation; the k-anonymity threshold gates the final tile render, preventing low-density areas from exposing individual patterns.

Architecture decisions:

• Spark batch over Parquet is the cheapest way to process petabytes at monthly cadence. The prior single-node C pipeline could not keep up because it required one S3 GET per activity.^[10:2]
• Path rasterization (drawing polylines between GPS samples) rather than per-point splatting produces more accurate visual output.^[10:3]
• Monthly rebuild cadence balances compute cost against privacy-change propagation speed.^[7:2]

Anti-cheat and leaderboard fairness#

Leaderboards are only meaningful if the data is honest. Strava's anti-cheat evolved from a rules-only system to a rules-plus-ML pipeline.

Rules layer: Flags world-record-breaking times, superhuman climb rates, and impossible speeds. A December 2024 rules update removed 6.5 million anomalous activities.^[4:5]

ML layer: A supervised model trained on human-flagged data catches subtler cases: e-bikes logged as regular bikes, car rides uploaded as runs, and GPS-edited files. The May 2025 ML backfill on run segment top-100 leaderboards removed 4.45 million activities; the January 2026 ride backfill removed 3.9 million.^[4:6][15]

Historical backfill: New model versions must be applied retroactively to existing leaderboards. This is a first-class operation, not an afterthought. Strava's engineering team spent "over a year and a half" coordinating the backfill infrastructure.^[4:7]

New activities pass through rules then ML; model upgrades trigger historical backfills that re-score existing leaderboard entries.

Real-World Example#

Strava's leaderboard infrastructure underwent a major rebuild in 2018, driven by the need for an ordered, partitioned, replicated backing store that multiple accessory systems could subscribe to independently.^[2:1][16]

Before: Segment efforts were written synchronously to a database. The leaderboard, feed, notifications, and achievement systems all queried the same store. Coupling was tight; adding a new consumer required schema changes.

After: The platform team introduced a Kafka-backed event stream. Every segment effort produces an event partitioned by segment_id. Consumers subscribe independently: the leaderboard consumer issues ZADD to Redis sorted sets^[17], the feed consumer pushes to follower inboxes, the notification consumer fires PR alerts, and the achievement consumer checks for milestone badges.^[2:2]

Redis serves as the ephemeral cache "to more quickly and effectively service the majority of their reads."^[18] Each leaderboard is a sorted set keyed by (segment_id, timeframe, sport) with elapsed milliseconds as the score. ZADD inserts or updates an effort at O(log N); ZRANGE reads a page; ZRANK returns a user's position.^[17:1]

The challenge leaderboard subsystem (for time-windowed goals like "ride 200 km in January") hit separate bottlenecks in 2020 and required its own rewrite to handle millions of concurrent participants.^[19]

Scale insight: Strava's Geo team built an internal key-value store called Rain for scale-tier map data (OSM aggregations, elevation datasets, activity-derived GPS).^[20] Map rendering moved to a proprietary engine in 2025 after Mapbox volumes became uneconomical.^[21]

Trade-offs#

The single biggest meta-decision: server-side vs client-side segment matching. Client-side saves enormous backend compute but makes anti-cheat impossible. Strava's removal of 14.85M activities proves server-side is non-negotiable for any system where leaderboard integrity matters.

Scaling and Failure Modes#

At 10x load (100M activities/day): The segment matcher becomes the bottleneck. Mitigation: horizontally scale matcher workers partitioned by geographic region; pre-compute H3 cell indexes at upload time so the matcher does zero spatial computation.

At 100x load (1B activities/day): Kafka partition count must scale to thousands. Redis sorted sets for popular segments become hot keys. Mitigation: per-timeframe ZSET splitting, read replicas for leaderboard GETs, and Kafka-backed async writes with batched ZADD consumers.

At 1000x load: The heatmap rebuild over petabytes of Parquet becomes a multi-day job. Mitigation: incremental per-tile updates (only reprocess tiles whose constituent activities changed) rather than full rebuilds.

Failure modes:

• Segment matcher backlog: If matcher workers fall behind, activities appear without segment efforts for minutes. Degraded mode: show activity immediately with a "matching in progress" badge. Kafka retention (24h) ensures no data loss.
• Redis shard failure: Sentinel promotes a replica. During failover, leaderboard reads return stale data. The Kafka event stream enables full replay to rebuild any lost ZSET.
• Heatmap privacy regression: A code change disables the k-anonymity filter. Detection: automated test that verifies tiles in known-sparse areas render blank. Response: halt tile serving from CDN, rebuild from last known-good pipeline version.

Common Pitfalls#

Follow-up Questions#

Exercise#

Exercise 1: Sizing the segment matcher#

Your segment library has 20 million segments. You receive 2 million activity uploads per day. Each activity traverses an average of 500 H3 resolution-11 cells. Each segment covers an average of 50 H3 cells. Estimate: (a) the number of candidate matches per activity after the H3 pre-filter, and (b) the total DTW computations per day.

Key Takeaways#

• Two-stage segment matching is the core architectural insight. H3 pre-filter reduces candidates from millions to ~100; DTW handles the precise match. Skipping the pre-filter is the difference between 1B and 10^14 comparisons per day.
• Server-side matching is non-negotiable for leaderboard integrity. Client-side detection saves compute but makes anti-cheat impossible.
• Privacy is a design input, not a toggle. The 2018 heatmap incident is the canonical cautionary tale: k-anonymity thresholds, privacy zones, and opt-out must gate aggregation before rendering.
• Kafka event streams decouple leaderboard writes from accessory systems. Feed, notifications, and achievements subscribe independently without coupling to the matcher.
• Anti-cheat requires historical backfill as a first-class operation. New ML models must re-score existing leaderboards, not just new activities.

Further Reading#

• Strava Engineering: Building the Global Heatmap (2017). The Spark/Scala rewrite that processed 1.4T points; explains path rasterization and the shift from per-activity S3 GETs to bulk Parquet access.
• Strava Engineering: Rebuilding the Segment Leaderboards Infrastructure, Part 3. The Kafka-backed event-stream design that decoupled leaderboard writes from accessory consumers.
• Strava: Keeping Segment Leaderboards Fair (2026). The rules+ML anti-cheat pipeline and the 14.85M-activity backfill across three sweeps.
• Wired UK: Strava heatmap a "clear risk" to security. The MoD assessment and policy fallout from the 2018 incident.
• Uber H3 documentation. Hierarchical hexagonal indexing: resolution tables, gridDisk, and the aperture-7 parent/child hierarchy used for the geospatial pre-filter.
• Newson and Krumm, "Hidden Markov Map Matching Through Noise and Sparseness" (SIGSPATIAL 2009). The canonical algorithm behind OSRM Match; relevant for snapping noisy GPS to road networks.
• Redis: Build a Real-Time Leaderboard with Sorted Sets. ZADD/ZRANGE/ZRANK at O(log N); the pattern powering per-segment rankings.

Flashcards#

References#