# Design a Strava-Style Fitness Tracker: GPS, Sensors, and Social

Source: https://www.techinterview.org/post/3233474991/design-fitness-tracker-strava-mobile/
Updated: 2026-07-26 · techinterview.org

Designing a fitness tracker like Strava is a great mobile [system design](/category/system-design/) question because it combines hardware (GPS, accelerometer, heart rate sensor pairing), real-time data capture, offline-first storage, and a [social feed](/post/3233474168/system-design-twitter-news-feed-timeline-fanout-on-write-fanout-on-read-celebrity-problem-ranking-caching/). The interviewer wants to see if you can balance accuracy, battery life, and reliable upload after a 3-hour ride.

## Functional requirements

- Record outdoor activities: GPS track, heart rate, cadence, elevation, time

- Pair with Bluetooth sensors (heart rate strap, power meter, bike computer)

- Upload activities to server when network is available

- Browse a feed of friends' activities

- View own history and stats

## Architecture

Three modules: **recorder**, **uploader**, **feed**.

## Recorder

Foreground service (Android) or background mode with active GPS (iOS). Samples every 1 second. Each sample: timestamp, lat/lon, altitude, accuracy, heart rate (if connected), cadence, power.

Samples are buffered in memory and flushed to local SQLite every 30 seconds. Crash-safe: if the app is killed mid-ride, on relaunch we resume from the last persisted sample.

## Sensor pairing

Bluetooth Low Energy (BLE) for heart rate, ANT+ for cycling sensors (Android only). Maintain persistent connection during recording; reconnect aggressively if dropped.

Some workouts last 10+ hours (ultra rides, marathon prep). Connection drops happen — handle with grace, fill gaps with interpolation or "no data" markers.

## GPS strategy

iOS: `CLLocationManager` with `desiredAccuracy = kCLLocationAccuracyBest` in foreground; `kCLLocationAccuracyBestForNavigation` only when explicitly needed (drains battery faster). Background updates require always-allow permission.

Android: `FusedLocationProviderClient` with `PRIORITY_HIGH_ACCURACY` and a foreground service notification.

## Battery optimization

- Reduce GPS sample rate to 5 seconds when stationary (detected via accelerometer)

- Auto-pause: detect speed = 0 and pause recording

- Disable cellular data sync during recording — upload after

## Upload

After workout finishes, the recorder serializes the entire track (typically ~50KB compressed for an hour) and queues for upload. Upload retries on failure with exponential backoff. Background upload via `URLSession` background config (iOS) or WorkManager (Android) survives app kill.

## Feed

Server-ranked feed of friends' activities with thumbnail map images, summary stats. Standard feed-style architecture: paginate, prefetch, cache. Most activity feeds fan out on write — push a new activity into each follower's feed list the moment it's saved — which keeps reads cheap and predictable; a fanout-on-read approach fits the rare athlete followed by tens of thousands of people, where writing to every follower is wasteful. Precompute the summary stats and render the route map to a thumbnail image once at upload time, then serve it from a CDN, so the feed never re-draws a full GPS track on the client. Interviewers often push on how you rank the feed (recency versus engagement) and how you keep a scrolling feed smooth on a phone.

## Frequently Asked Questions

### How do you handle GPS jitter?

Discard points with low accuracy (>50m). Apply a smoothing filter (Kalman or simple moving average) to reduce zigzag in the recorded track.

### What if the user starts a workout with no GPS lock?

Begin recording sensor data and time. Show "GPS searching" UI. Backfill GPS once locked. Some implementations refuse to start without a lock.

### How is elevation calculated?

GPS-reported altitude is noisy. Better: barometric pressure from the device's pressure sensor (iPhone 6 and later, most Android flagships). Calibrate against GPS altitude periodically.