AI & Technical question

How does the system design for Strava work?

Practice this question out loud. An AI interviewer asks it, follows up like a real interviewer would, and scores your answer. Type or speak.

What this question tests

Technical understanding of how a GPS fitness tracking app is architected end to end, from mobile data capture to the social feed.

Clarify scope: the mobile GPS capture pipeline, backend ingestion and storage, or the social feed and leaderboard system.
Describe client-side capture: phone or watch GPS and accelerometer sampling, buffered locally, then uploaded once the activity ends.
Describe ingestion: the backend validates and smooths the GPS track, removing jitter, and computes derived stats like pace and elevation.
Explain segment matching: comparing the uploaded route against a spatial index of known segments to detect matches and update leaderboards.
Cover storage and fanout: activities stored per user, then fanned out to followers' feeds, similar to a social feed architecture.
Note scaling: segment leaderboard recomputation is the heaviest part, since a popular segment gets many new attempts daily.

Breaks the system into clear layers, capture, ingestion, processing, social, instead of one vague description.
Identifies segment matching and leaderboard updates as the hardest, most Strava-specific technical problem, not generic CRUD.
Mentions geospatial indexing, such as a quad-tree or geohash, as the mechanism for efficient segment matching.
Addresses offline capture and later sync as a real mobile constraint.

How would you handle GPS inaccuracy in dense urban areas?
How would you scale leaderboard updates for a segment with millions of attempts?
How would you detect fraudulent, car-assisted activity uploads?