Design Strava: GPS Activity Tracking, Live Location and Leaderboards

The first requirement is recording: a run or ride is captured with GPS, and the athlete gets back the route, total distance, pace and elapsed time. Second, during an activity the athlete can share a live position with selected contacts, mainly as a safety feature for solo runs and long rides.

Third, a feed shows recent activities from the athletes a user follows. Fourth come segments, which are well-known stretches of road or trail, each carrying a leaderboard of the quickest recorded times. Training plans, clubs and route planning are left out; they add product surface without changing how GPS data flows through the system.

Offline support comes first. Trails, mountains and rural roads often have no coverage, so the phone must record entirely on-device and sync when a connection returns. Durability is equally strict: a completed marathon that vanishes is a disaster for the user's trust, so every finished activity must be stored safely and uploads must be retry-safe.

The feed should open in under 200 ms, which means it cannot be assembled from scratch by scanning raw tracks. Leaderboards, by contrast, can tolerate being eventually consistent. If a new personal best appears on a segment a few seconds after upload, nobody minds, and that slack lets heavy processing happen asynchronously.

Assume about 10 million activities are uploaded per day, roughly 116 per second on average, with weekend mornings running perhaps five times higher. A one-hour activity sampled once per second contains around 3,600 GPS points.

At roughly 100 KB per activity, that comes to about 1 TB of new GPS data each day and around 365 TB per year. Live tracking adds a very different load: if about 1 million athletes share their position every 5 seconds, the backend receives roughly 200K small location updates per second. The key lesson from these figures is that a recorded track is a sizeable blob read as a whole, which points toward object storage rather than billions of individual database rows.

The entities are Athlete, Activity, GPS track and Segment effort, where an effort is one athlete's elapsed time over one segment. Keeping the track separate from the activity record lets metadata live in a database while the bulky point data lives elsewhere.

POST /activities sends the summary (type, start time, distance, duration) and returns an activity ID plus a pre-signed upload URL for the GPS file. During live tracking, POST /live/{session_id}/points accepts a small batch of latitude, longitude and timestamp triples and returns 204 with no body, keeping each call as light as possible. GET /feed returns activity summaries with cursor-based paging, and GET /segments/{id}/leaderboard returns the top efforts along with the caller's own rank.

The phone records locally whether or not it has signal. When the athlete finishes and connectivity is available, the app calls the API gateway, and the activity service writes the summary into a Postgres activity database and hands back a pre-signed URL. The app then uploads the full GPS file directly to object storage such as S3, so multi-megabyte payloads never consume capacity on our application servers.

When the upload completes, an event lands on Kafka. Track processors pick it up, load the file from object storage, smooth out noisy or jumpy points, and compare the route against known segments. Every segment the route completes produces an effort, and its time is pushed into leaderboards held in Redis sorted sets. Separately, a feed service assembles each user's feed from recent activities of the athletes they follow, with a cache in front so the 200 ms target holds.

Storing each GPS point as its own row is the most query-friendly option, but 10 million activities times 3,600 points is about 36 billion new rows every day. Indexes balloon, writes slow down and the bill grows fast. A time-series database is designed for timestamped samples, yet the volume is just as large, and it optimizes for queries we almost never run, such as fetching a single point.

The access pattern settles it: a track is nearly always read in full, to draw a map or to match segments. So each activity becomes one compressed file in object storage. Consecutive GPS samples are only meters apart, so delta encoding, storing each point as a small offset from the one before, typically shrinks files five to ten times.

For feed thumbnails, the full track is overkill. A simplified polyline of a few hundred points is kept directly in the database, so maps render without opening the file. Lifecycle rules move older tracks to cheaper storage classes automatically. One compressed file per activity is cheap, durable and fast to read in one request.

Handling 200K live updates per second starts on the device. Instead of transmitting each GPS fix, the app accumulates points and sends a single compact batch roughly every 5 seconds, which saves both battery and mobile data and cuts request volume dramatically.

Those batches hit a stateless live tracking service that verifies a session token so only the athlete can write to their own session. The service stores just the current position and a short trailing window of recent points in Redis, sharded by athlete ID so load spreads evenly. People following along receive new points through server-sent events; since each athlete has only a handful of watchers, the push cost is small.

Every live key carries a TTL, so Redis cleans up after itself once the activity ends. Nothing here needs to be permanent, because the complete, full-resolution track arrives through the normal upload path after the workout.

Each upload needs to be checked against a catalog of millions of segments, so brute-force comparison is out. A geo index based on geohashes narrows the search to segments that fall within the route's bounding box, leaving only a few candidates. For each candidate, the processor confirms that the route passed near the segment's start and then its end, in that order, within a tolerance of a few meters.

A successful match produces a segment effort with its elapsed time, written to the database as the source of truth. Each segment also has a Redis sorted set scored by time, and a new score replaces the old one only when it is faster, so the set holds each athlete's personal best. Reading the top ten is then a cheap range query.

Filtered views, such as an age group, a user's friends or only this year, would multiply the number of sorted sets enormously. Those boards are computed from the efforts table when someone asks for them and cached for later requests.

Keeping GPS data as files rather than rows is cheap and straightforward, but individual points cannot be queried with SQL. Processing uploads asynchronously makes the upload itself finish immediately, at the cost of leaderboards updating a few seconds later.

Holding live tracking data only in memory keeps that path fast and inexpensive; if a point goes missing, the uploaded file still contains it. Precomputing the main segment boards makes them instant, while rarely used filtered boards are generated on demand and cached. Put briefly: store tracks as files, push heavy work through queues, and rank with sorted sets.