System requirements

Track physical activity like walking, running, swimming etc

Functional:

• Users choses an activity and we call activity API to track activity
• Users can set goals
• Users can monitor progress
• User can login from multiple devices

Non-Functional:

• Scalability: Scale per users and per activity
• Extensibility: we should be able to easily extend our activities
• Security: Users can activity should be private
• Availability: App should be highly available as we may have users across the globe and many users concurrently available

Capacity estimation

• 1 Million total users
• 25% DAU = 250K DAU
• Engagement is 3 times a day, so Queries Per Day = 750K, 5 QPS
• User data = 1MB, 250K = 250GB
• Engagement Data = 10KB/User = 10KB * 750K = 7.5 GB per day, 75GB for 10 years
• 250 + 75 = 325GB storage

API design

• Login API, user is saved to DB
• Fitness App to Activity API, verify if a valid user
• Start a task never ending if an Activity is selected
• Tasks spins workers that track users activity. Activity is stored in Activity DB.
• Activity monitoring is two-fold as goal and progress. so, we need task for each.
• For each activity type; for fast processing, we will use cache to store users activity per day (and expire the entries older than a day). If cache is miss we read from DB and update cache

Database design

We will use relation DB. As our Data is fairly structured and way under 5TB.

We will maintain tables as follows,

• Users - To manage users log
• Activity_Goals - For an activity user goals
• Activity_progress - Track Activity

High-level design

Request flows

Detailed component design

• We have chosen worker pattern. For each Activity_Type we will have a task running, this is a forever running task. When an engagement happens, a relevant task gets triggered which spin-up workers to process requests. for example task() starts a task and then, task.rx() is the receiver as soon as task sends an event.
• We have chose cache to be for a day as our engagement data per day is just 7.5 GB
• When storing activity stats, we acquire DB lock and we only have 3 engagement per second, so lock should be fine to avoid race conditions

Trade offs/Tech choices

• We chose worker pattern against queue pattern as with queue we will need to batch the requests or still have workers processing from queue. whereas we can employ a worker pattern w.r.t tasks

Failure scenarios/bottlenecks

• We will need to monitor following KPIS
  • Cache size, if cache gets bigger we may need to shorten the TTL from day to hours
  • We write to Activity DB with Lock. we will need to monitor if Lock gets released timely or not. else we may hinder our app performance

Future improvements

If we see large activites, we can start Queue per activity and employ workers to process queues