Designing a fitness tracker like Strava is a great mobile system design question because it combines hardware (GPS, accelerometer, heart rate sensor pairing), real-time data capture, offline-first storage, and a social feed. 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.
Keep sharpening your system design:
