Design Strava

Record runs and rides offline, process each upload into a map, stats and segment efforts, and rank them for 100 M athletes.

Last updated 2026-10-26. Difficulty: hard. Patterns: geospatial, async-pipeline, spatial-matching, leaderboards, privacy. Reported at Strava, Google, Apple, Meta, Amazon, Uber.

Functional requirements

• Record a run or ride. GPS once a second plus heart rate, cadence and power where a sensor exists, on a phone or a watch, with no network at all. The device holds the only copy until the server has it.
• Upload and process the activity. The finished activity goes up as one compressed file, is acknowledged once stored, and is then processed into a map, distance, pace, splits and elevation. Retrying an upload never creates a second activity.
• View an activity. Map, stats, splits, segment efforts and achievements. The owner sees their own numbers within seconds, even on a Saturday morning.
• Follow athletes and see their activities in a feed. Friends’ activities, newest first, with a map thumbnail. The feed is the standard fan-out pattern; what is specific here is that it must not wait for segment results.
• Segments and efforts. A segment is a stretch of road or trail that athletes create. Every new activity is matched against every segment it completed, producing one effort (an elapsed time) per pass.
• Segment leaderboards. Each athlete’s best effort per segment, ranked. Views by this year, gender, age group and people you follow; the top 10 plus your own rank with neighbours.
• Privacy controls. Privacy zones hide any part of an activity near home or work. Visibility is everyone, followers or only me, and only public activities count on public leaderboards.
• Live tracking for safety. Optional: share a live position with chosen contacts during the activity (Strava calls this Beacon). Best effort, and independent of the recording.
• Out of scope. Route planning, heatmaps, training analytics, clubs and challenges, kudos and comments, subscriptions, and building the device-partner sync itself (partner uploads arrive through the same upload API).

Non-functional requirements

• Scale (100 M athletes · 40 M uploads/week). Not uniform: weekend mornings run about 5× the average for three hours. Tens of millions of segments, a few with millions of efforts.
• Never lose or duplicate an activity (0 lost · 0 duplicated). Losing a marathon is the failure athletes never forgive. Mobile networks at the end of a run are poor, so every upload is retried, and a retry must land on the same activity.
• Upload acknowledgement (p99 < 1 s after the last byte). The acknowledgement means "your file is stored durably", nothing more. Processing never sits inside the request.
• Time to see your own activity (stats p95 < 10 s · segments p95 < 2 min). At the weekend peak too. This drives the hardest tradeoff: splitting processing into lanes so the athlete’s own view never waits behind shared systems like the segment index and the leaderboard database.
• Location privacy (no zone point ever shared). No surface other than the owner’s own view may show a point inside a privacy zone: maps, feed thumbnails, segment efforts, the public API, embeds, aggregates. One leak exposes where someone lives.
• Leaderboard reads (p99 < 200 ms). Top 10, your rank and your neighbours, even on a board with 400 k athletes. The board must count only each athlete’s best and be rebuildable from the efforts.
• Recording availability (works with no network). Recording never depends on the server. Live tracking is best effort and may drop points; the recorded file may not.

Back-of-envelope estimates

• Uploads per second: ~66 avg · ~330 peak. 40 M uploads a week ÷ 604,800 s ≈ 66/s. Weekend mornings run about 5× the average as Europe, then the Americas, finish their long runs and rides: ~330/s. Small in absolute terms; the shape (a predictable 5× step for three hours) is what the design has to handle.
• Size of one activity file: 3,600 points · ~300 KB. An average activity is about an hour at one point a second: 3,600 points. Each carries time, latitude, longitude, altitude and, from a watch, heart rate, cadence and power: ~80 B in a compact binary format, so ~290 KB. Budget 300 KB per upload; a long ride is a few MB.
• Raw file storage: ~0.6 PB/year. 40 M × 52 ≈ 2.1 B activities a year × 300 KB ≈ 620 TB/yr of raw files, kept forever because every derived result is recomputed from them. Processed streams (the owner’s full copy and a trimmed display copy) roughly double it. Peak ingest is only 330 × 300 KB ≈ 100 MB/s: bandwidth is not the problem.
• Processing CPU at peak: ~330 cores. Parsing, cleaning, elevation correction against a terrain model, stats, splits and rendering the map image take roughly 1 s of CPU per activity. 330/s × 1 s = 330 busy cores at peak against ~70 on average. A small fleet: the risk is that it must grow 5× within an hour, not what it costs.
• Candidate segments per activity: ~1,000 → ~50 → ~25 ms. A 15 km track, buffered by 50 m, covers about 40 S2 level-13 cells (~1 km across). Active areas have ~25 segment start points per cell: ~1,000 candidates. Checking that the track passes near both the start and the end keeps ~50, and the precise match costs ~0.5 ms each: ~25 ms per activity. Brute force would test 30,000× as many segments.
• Efforts written: ~3,300/s at peak. A typical activity completes ~10 segments (city routes far more, rural ones none). 330/s × 10 = 3,300 efforts/s at peak, ~660/s on average. A year is ~21 B efforts × ~100 B ≈ 2 TB. Only an effort that beats the athlete’s own best changes a leaderboard, a small fraction of these.
• Leaderboard storage: ~5 B rows · ~500 GB. 30 M segments, but a board holds one row per athlete, not per effort, so a commuter who rides a segment 500 times a year is one row. Across the all-time and this-year windows that is ~5 B rows; at ~100 B with indexes, ~500 GB. Most boards are tiny (median under 100 athletes); the largest have ~400 k athletes and millions of efforts behind them.
• Activities in progress at peak: ~1.2 M. Little’s law: 330 activities finishing per second × ~3,600 s average duration ≈ 1.2 M being recorded at once. If 10 % share live tracking at one point per 15 s, that is 120 k ÷ 15 ≈ 8 k points/s: tiny next to a ride-hailing location stream, and nothing queries it by place.

Components

• Athlete app (phone · watch · offline-first): Records GPS once a second plus sensor data into a local file under an activity id it generates at Start, so recording never needs a network. A local outbox uploads the finished file with retries and keeps it until the server reports it processed. Sends a separate low-rate position stream only when live tracking is on.
• API gateway (auth · rate limits · routing): Terminates TLS, authenticates athletes and partner apps, rate limits per token and routes to the services. Stateless. Caps request bodies so a 300 KB run and a 5 MB multi-day ride pass but a 1 GB file does not.
• Activity service (idempotent PUT by activity id): Accepts a file at PUT /activities/{activity_id}, writes it to object storage, creates the activity row and enqueues processing, then acknowledges. The device-generated id makes every retry land on the same row. Also serves the activity page, checking visibility on every read and returning the trimmed track to anyone but the owner.
• Activity files (object storage · raw + streams): Immutable raw uploads, kept forever as the input to every reprocessing and readable only by the processor and the owner’s export. Processed streams are stored as two objects: the owner’s full track and the trimmed display track, which is the only one any shared surface can read. ~0.6 PB of raw files a year.
• Fast lane (Kafka · key = activity_id): Processing jobs the athlete is waiting for: parse, clean, trim, stats. Its workers are scaled up on a schedule before the weekend peak and autoscaled on the age of the oldest job, target under 5 s. Bulk imports and reprocessing never enter this lane, so a 2,000-activity history import cannot delay anyone’s Saturday run.
• Activity store (sharded by athlete_id): Activity rows (status, stats, summary polyline, visibility, processing version, the effort list with ranks) plus each athlete’s settings and privacy zones, co-located by athlete. Writes from processing are conditional on the processing version, so a repeated job cannot overwrite newer output. ~2 B rows a year at ~2 KB.
• Activity processor (parse · clean · trim · stats): Turns the raw file into an activity: parse, drop GPS spikes, smooth, detect pauses, correct elevation, apply privacy zones, compute stats and splits, render the map image. Deterministic given the file, the athlete’s settings and the processing version, which is what makes reruns safe. It does not snap the display track to roads: trails are not on the road graph and athletes want their own line.
• Segment lane (allowed to lag at peak): Segment-matching jobs, published once the trimmed track exists. It may run a minute or two behind on a Saturday morning, because segments depend on shared systems that must never delay the athlete’s own stats. A separate background topic for backfills and reprocessing is read only when this lane is empty.
• Segment matcher (in-memory S2 start-cell index): Finds every segment the trimmed track completed. Holds an index of all 30 M segment start points by S2 level-13 cell (~2 GB) in memory, so candidates cost hash lookups rather than database queries; prefilters on the end point; then walks each candidate’s polyline in order with a tolerance. ~25 ms per activity; one effort per completed pass.
• Segment store (polylines · versions): Segment definitions: polyline, length, grade, version and state (active, flagged, hazardous), ~30 M at ~1 KB each. A nightly snapshot plus a change stream keep every matcher’s in-memory index current. Editing a polyline bumps the version and queues a background re-match of that segment’s efforts.
• Leaderboard service (best-only writes · views): The only writer of efforts and best-effort rows, and the reader of every board. Records an effort and lowers the athlete’s best for each window only if the new time beats it, in one transaction on the segment’s shard. Serves the top 10, the viewer’s rank and neighbours, filtered views, and the following view computed on read.
• Efforts DB (sharded SQL · by segment_id): Two tables on the same shard: every effort (~21 B a year) and best_efforts, one row per (segment, period, athlete) carrying gender and age bracket. Ordered indexes on (segment, period, elapsed) and (segment, period, gender, age bracket, elapsed) make each shared view an index prefix. Sharding by segment keeps an effort insert and its best-row update in one local transaction.
• Leaderboard cache (Redis · top-N · histograms): The top 10 per (segment, view), rewritten only when a new best enters it. For boards above ~10 k athletes, a count of athletes per elapsed second (~12 KB a view) that turns "how many are faster than me" into one small read. Derived entirely from the Efforts DB and rebuilt nightly for the big boards.
• Feed service (follow graph · fan-out): Owns the follow graph and fans each processed activity id out to followers’ feeds: fan-out on write, with fan-out on read for athletes with huge followings (the News Feed pattern). Stores ids, not copies, so segment results and edits appear without a second fan-out. Respects visibility: followers-only activities reach followers, only-me activities reach nobody.
• Live tracking (Redis · TTL · 1 point / 15 s): Receives one position and battery level every 15 s per session and keeps the last hour in a capped Redis list with a TTL; safety contacts poll it through an unguessable link. Lossy by design: a missed point is superseded by the next one. Separate from recording and upload, so it can fail without touching the activity.

User flows

1. Finish a run offline and upload it. The core write. The phone holds the only copy of the run, so the server’s single job inside the request is to make that copy durable and say so; everything else happens after the acknowledgement.
   1. The app records a point every second into a local file under an activity id it generated at Start. The id is a UUIDv7 created on the device, so recording needs no network and the id exists before any request is made. Points are appended and flushed every 10 s, so a crash or a dead battery loses at most 10 s. A watch that syncs to the phone later carries the same id inside its file.
   2. On Save, the app compresses the file and PUTs it to the Activity service at a URL containing that id. A PUT to a client-chosen URL is idempotent by definition: the same request twice means the same resource. One request carries the whole ~300 KB file; at this size a presigned two-step upload adds round trips on a weak signal and saves nothing.
   3. The service writes the file to object storage under a key derived from the athlete and the activity id. Writing the file first means a row never exists without its file. The key is deterministic, so a retry overwrites identical bytes instead of creating a second object; an object with no row after a day is deleted by a lifecycle sweep.
   4. It inserts the activity row in state received; an id that already exists inserts nothing. The primary key on the device id is the deduplication. If the row exists with the same file hash, this is a retry and the service returns the current status; with a different hash it is a client bug and gets a 409 rather than silently replacing a recorded activity.
   5. It enqueues a processing job on the fast lane, keyed by activity id. Keying by activity id sends every job for one activity to one partition, in order. A crash between the insert and the enqueue is covered by a sweeper that re-enqueues any activity still received after 5 minutes; processing is idempotent, so an extra job costs only CPU.
   6. The service returns 202; the app marks the upload done but keeps its copy until the activity is processed. The acknowledgement means "your file is safe", nothing more, and takes ~100–300 ms. The app deletes its copy only once the status reaches processed, so even an object lost in storage would be recoverable from the phone.
2. Saturday morning: stats first, segments later. The asynchronous path at the weekend peak of ~330 uploads a second. The athlete’s own view depends only on their file; segments depend on shared systems and are allowed to lag by a minute or two.
   1. A fast-lane worker takes the job and reads the raw file. Fast-lane workers were scaled up on a schedule before the morning and autoscale on the age of the oldest job, target under 5 s. A file that fails to parse three times is marked failed with a reason instead of retrying forever; the raw file stays for a parser fix.
   2. The worker cleans the track: drops spikes, smooths, detects pauses and corrects elevation. A point implying 80 km/h on a run is dropped; smoothing removes the zig-zag that inflates GPS distance by a few percent; speed under ~1 km/h for 10 s counts as a pause. GPS altitude is off by 10–20 m, so elevation comes from the barometer if the watch has one and otherwise from a terrain model, and climbs under a few metres are ignored so noise does not add phantom gain.
   3. It loads the athlete’s privacy zones and cuts every point inside them from the display track. This produces two tracks: the full one, readable only by the owner, and the trimmed one, the only input to the feed, map images, segments and the public API. The cut lands a jittered distance past the zone edge, seeded by the activity id, so many activities’ cut points do not trace a circle around the home.
   4. It computes stats on the full track and writes both streams and the processed activity. Distance and moving time come from the full track, so a privacy zone never changes the athlete’s numbers. The streams are written first under versioned keys, then the row, conditional on the processing version, so a slower duplicate worker cannot overwrite newer output.
   5. It publishes activity.processed for the feed and a job on the segment lane. The feed fans the activity id out to followers now, without waiting for segments. The segment job is keyed by activity id and processing version so consumers can drop duplicates.
   6. The athlete opens the app and sees the map, distance, pace and splits. Upload to processed is ~5–10 s at p95 even at the peak. The page shows "segments processing" until the segment lane catches up, typically within a minute and within 2 minutes at the worst of the morning.
   7. A matcher takes the segment job and finds candidate segments from its in-memory index of start points. The trimmed track is covered by ~40 S2 cells; the index returns the ~1,000 segments that start in them; an end-point check keeps ~50, whose polylines come from a local cache backed by the segment store. Each survivor is then walked in order with a tolerance (see the matching deep dive).
   8. The leaderboard service records each completed pass and lowers bests only when beaten; the matcher stores the results on the activity. One transaction on the segment’s shard inserts the effort and conditionally lowers the athlete’s best for each window; only an improvement touches the board, its top 10 cache and its histogram. Ranks and achievements (PR, top 10) are computed here and stored on the activity, so viewing an activity never queries a leaderboard.
   9. A follower opens their feed: activity ids come back and are hydrated with the latest stats and segment results. Because feed entries are ids rather than copies, the PRs that landed a minute after the fan-out show up with no second fan-out. Hydration is a batch read from the activity store that applies the same visibility rules as the activity page.
3. Open the leaderboard of a hot segment. The main read, at its hardest: a park loop with 2 M efforts from 400 k athletes, opened ~50 times a second on a Saturday. The top 10, a rank of 237,000, a filtered view and the people you follow, each in milliseconds.
   1. The app opens the segment page and asks for the overall board around the viewer. One call returns what is on screen: the top 10 and the viewer with two neighbours either side. Filtered views and the following tab are separate calls made when tapped.
   2. The top 10 is read from the cache, which changes only when a new best enters it. On a popular board a time enters the top 10 a few times a month, so this key is read millions of times per write. The leaderboard service also holds it in local memory for a few seconds, so the hottest board does not concentrate on one Redis shard.
   3. The viewer’s best time comes from their best-effort row; their rank comes from the board’s histogram. Times are whole seconds in a narrow range (this loop: ~900 to ~4,000 s), so a count of athletes per second answers "how many are faster" exactly in one ~12 KB read: rank = the sum of the counts below 1,412 s, plus one. A COUNT(*) over the index would read 237 k entries per request.
   4. Neighbours above and below come from two short index scans around the viewer’s time. Two LIMIT queries on the ordered index cost a few page reads each, however deep the rank. Equal times share a rank and are listed by who did it first.
   5. The viewer taps "Women, 35–44, this year": the same three reads run against that view’s index prefix and histogram. Gender, age bracket and period are columns on the best-effort row, so every shared view is a prefix of one index and nothing extra is written per view. Histograms exist only for views of boards above ~10 k athletes and are built on first read; smaller views just count rows.
   6. The following tab fetches the viewer’s follow list and looks up just those athletes’ best rows. This view differs for every viewer, so it is never precomputed. Following ~150 people means 150 primary-key lookups on the segment’s shard, sorted in memory, ~5 ms. On a small segment the service scans the board and intersects instead, whichever side is smaller.
4. A lost acknowledgement and a crashed worker. The two classic duplicate makers: a phone that never saw the 202 uploads again, and a worker that dies halfway has its job redelivered. Neither may produce a second activity or a second effort.
   1. The first upload stores the file and the row, but the 202 is lost as the phone leaves coverage. From the phone’s side the request failed; from the server’s side it succeeded and processing has started. A server-generated id cannot handle this case: the phone would never learn the id it was given.
   2. The app’s outbox retries with backoff, sending the same id and the same bytes. Retries back off exponentially with jitter and survive an app restart, because the outbox is on disk. The athlete sees "uploading", not an error.
   3. The service finds the existing row with the same hash and returns its status without creating or enqueueing anything. Same id and same hash is a retry: return 200 with the current status. Same id with a different hash is refused with 409, so a buggy client cannot overwrite a recorded activity. A different id for the same run (watch and phone both uploading) is another problem, caught later by a start-time and track-overlap check.
   4. Meanwhile a processor crashed after writing the stats but before publishing; the job is redelivered to another worker. The worker commits its queue offset only after its last side effect, so a crash anywhere means the whole job runs again. That is safe only because every step is written to be repeated.
   5. The second worker recomputes from the immutable file; its conditional write finds version 7 already stored and changes nothing. Processing is a pure function of the raw file, the athlete’s settings and the processing version, so the rerun produces the same output, including the privacy cut, whose jitter is seeded by the activity id. Stream objects live under versioned keys, so rewriting them is harmless.
   6. It publishes the feed event and the segment job again; every consumer drops the duplicate by key. The feed adds the activity id to each follower’s feed as a set member, so a second fan-out is a no-op. Efforts carry effort_id = hash(activity_id, segment_id, pass), so a second match writes the same rows, and taking the minimum of a best time is idempotent anyway.
5. Live tracking for a safety contact. A low-rate, lossy stream beside the recording, never instead of it. The contact sees where the athlete is every 15 seconds; the activity itself still comes from the uploaded file.
   1. The athlete starts a run with live tracking on; the app opens a session and texts a link to their safety contacts. The link carries an unguessable 128-bit token scoped to this one session, so it works without an account and cannot be enumerated. Strava calls the feature Beacon; the mechanics here are a design, not Strava’s documented internals.
   2. Every 15 s the app sends its latest position and battery level, while recording continues locally at one point a second. One small request every 15 s, coalesced with other radio use, costs far less battery than a persistent socket that drops on every cell handoff. A failed send is not retried: the next point supersedes it.
   3. The Live service appends the point to a capped list that expires. Nothing queries live sessions by place, so unlike a ride-hailing system there is no geo index: just a list per session, trimmed to the last ~240 points (an hour) and expiring a day after the last write. Privacy zones are deliberately not applied: a safety contact needs the true position, and only they can see it.
   4. The contact opens the link and their browser polls for new points every 15 s. Polling at the update rate means a push channel buys nothing. If no point has arrived for 10 minutes the page says so, with the last battery level, which is the most useful safety signal the feature gives.
   5. At Save the session ends and the uploaded file becomes the activity; the live trail expires. The live trail is never merged into the activity: it has one point every 15 s and gaps, while the file has every second. Keeping the two paths independent means a broken live service cannot lose or corrupt a recorded run.

Deep dives

The theory behind it

• Geospatial indexing and proximity search: Geohash, S2 and quadtrees, nearest-neighbour and radius queries, indexing moving objects, map tiles, and the accuracy and hot-cell problems that come with each.
• Media uploads and processing pipelines: How photo and video uploads work at scale: direct-to-storage uploads with presigned URLs, resumable and chunked uploads, processing pipelines for thumbnails and transcoding, metadata and status tracking, deduplication, moderation hooks and serving variants through a CDN.
• Idempotency keys in practice: How to make retried API requests safe: what idempotency means, client-generated keys, storing keys with request fingerprints and responses, handling concurrent duplicates, expiry, keys across service boundaries, idempotent consumers, and the mistakes that still cause double charges.

Related

• Design Google Maps
• Design Uber
• Design Post Search
• Design Nearby Friends
• All 83 system design interview questions
• Run this question for a friend: the interviewer kit