Design a GPS Fitness Tracking App with Activity Uploads and a Friends Feed

Design a mobile fitness-tracking service in the style of Strava. An athlete starts a workout in the app, which records the route from the phone's GPS and shows live elapsed time, distance and pace. When the workout ends, the athlete saves it with a title and sport type, and it appears on their profile with a map of the route and summary statistics. Athletes follow one another, and each athlete has a home feed of recent activities from the people they follow, where they can give kudos and leave comments. The report names only the product, so the scope below is the standard one for this prompt, written as assumptions. Be ready to go deep on how GPS data travels from the phone to durable storage, and on how the feed is built and served. ```hint Phone versus server Picture a trail run with no signal for most of an hour. Decide what the app must be able to do entirely on its own and what the server can do later. ``` ```hint Two sizes of data Compare the full route of a single activity with what a feed card needs to render, and ask whether one store should serve both. ``` ### Constraints and Clarifications - In scope: recording with start, pause, resume and stop; live statistics on the device; saving and uploading an activity; an activity page with a route map and summary; a profile history; following athletes; a home feed of followed athletes' activities; kudos and comments. - Out of scope unless the interviewer brings them in: segment leaderboards, route planning, clubs, messaging, wearable pairing and subscriptions. - Connectivity during a workout is unreliable. Recording must not depend on the network, and a finished activity must eventually upload even if the app is closed or the phone restarts. - An upload may be retried many times; the athlete must never end up with duplicate activities. - Each activity has a visibility setting, and no read path may show an activity to someone that setting excludes. - Scale, retention and latency targets are not given; agree on them before sizing anything. ### Clarifying Questions - How many athletes, recorded activities per day and feed loads should the design target, and how concentrated is the load (for example, on weekend mornings)? - Do followers need to watch an athlete's position live during a workout, or is sharing only after the activity is saved? - Which visibility options exist (everyone, followers, only me), and must the start and end of a route be hidden near an athlete's home? - How long is raw GPS data kept, and at what resolution? - Is the feed strictly reverse-chronological, or ranked? ### What a Strong Answer Covers - Functional and non-functional requirements, with offline recording and duplicate-free uploads called out explicitly - Back-of-envelope sizing of activities, GPS points and feed reads that justifies the storage and read-path choices - A recording and upload path that survives lost signal, app restarts and retries - A data model that keeps raw tracks apart from activity summaries and per-viewer feeds - A feed strategy with a clear fan-out choice, including athletes with very large followings - Visibility enforced on every read, plus failure handling and the metrics that show the pipeline is healthy ### Follow-up Questions - How would you let friends follow an athlete's position live during a race, and what would that cost in battery and server load? - How would you add segments, where every effort over a named stretch of road is detected, timed and ranked on a leaderboard? - Recorded tracks sometimes contain GPS jumps that imply impossible speeds. Where in the pipeline do you clean them, and what do you keep? - An athlete switches an old public activity to private. What has to happen, and how quickly?