Requirements

Functional Requirements:

• User is able to log their workouts - manually or auto pushed via fitness watches or native companian app on the watch.
• User is able to set goals
• User is able to track their goals
• User is able to view hisotry and basic stats

Scale estimations

• 100M DAU
  • 10% records workouts
  • So 10M writes per day
  • ~100 QPS for writes
• Read requests - on average 5 reads per DAU, including hisotry reads, stat reads, workout reads etc
• 500M reads per day
• ~500 QPS for reads

Non-Functional Requirements:

• Workout data should be highly consistent ensuring no data loss while goal and stat data is acceptable as eventual consistent updating after workout creation/updates
• Low latency - system should be quick enough to move through traffic without any abnormalities especially during high traffic times such as morning or late evenings
• Highly scalable - should be able to handle 1B unique workout records
• High read throughput - system should be able to handle read traffic efficiently
• Workout records should be idempotent ensuring no two duplicate records are created

Data entities:

User

Id

Name

Email

Workout

Id - PK, also idempotent key

userId - partition key

Source - App/Fitness Watch/ Native app

Type - Strength/Cardio

Intensity

TimeTaken

CaloriesBurned

CreatedAt

Goal

Id - PK

UserId - Partition key

GoalWeight

CurrentWeight

Type - lose, gain

PercentComplete

CompletedAt

CreatedAt

UpdatedAt

UserStats

id

UserId - Partition key

totalWorkout

TotalGoals

GoalsCompleted

CurrentWeight

CurrentHeight

APIs

Create workout

POST /{user_id}/workout

req - {

id - idempotent key

source,

time,

intensity,

type

}

res - { id }

Create Goal

POST /{user_id}/goal

req -

{

id,

type,

goalWeight

}

Get user stats

GET/{user_id}/stat

response -

{

userId,

totalWorkouts,

totalGoals,

GoalsCompleted,

GoalsInProgress,

}

//fetch a workout

GET /{user_id}/workout/{workout_id}

Res - Workout

Get workouts history

Get /{user_id}/workout?filters=

res - workoutList

High-Level Design

API Gateway

Acts as the entry point for all client requests.

Responsibilities:

• Authentication (if required)
• Rate limiting - token bucket per API key/IP to prevent abuse and control write traffic.

Load Balancer

Distributes traffic across multiple instances of the Read and Write services to improve scalability and availability.

Workout Service:

Responsibilities:

• Create workouts
  • Uses idempotency key to ensure duplicate records are not created
• Fetches workout history
  • First page of history is stored in Redis, so if cache hit, return immediately
  • If cache miss, get data from DB, stgore in Redis and return.
• Publishes workout created event to kafka
• Also consumes WorkoutFetched event from kafka to create the fethced workout from devices.

Goal Service:

Responsibilities:

• Creates goals
• Fetches goal
• Fetches goal progress
  • Used redis here to fetch goal progress, if found return from redis,if cahce miss go to DB.
• Subscribes to the workout created event and updates the goal progress accordingly.

Stats service:

Responsibilties:

• Fetches user basic stats.
• Flow:
  • Check Redis: if hit, return immediately
  • If miss, fetch from DB table UserStats
  • Store it in redis
  • Return data
• Subscribes to the workout created event and updates the stats in redis if present and as well as in DB.

Redis:

• Acts a cache layer, use to cache frequently accessed data.
• We will store:"
  • User stats : userId -> stats
  • Recent workouts : last 10-30 workouts
  • Goal progress
  • First page of workout history
• All the above is shown is user dashboard, so all of this will be cached.
• TTL-based + cache-aside pattern

Device Tracker Service

• Registers user device when to app, when user connects the device to our system.
• A background service running periodically that Fetches any newly recorded workouts from the registered device
• Publishes the WorkoutFetched event to kafka

Kafka:

Responsibilties:

• Acts as an async event backbone
• for all workout related events Uses userId as partition key

Detailed Component Design

We will now deep dive into the following topics

1) Offline Sync + Idempotency Key:

• Whenever a user is offline, opens app and uploads/records workout, the system needs to ensure that workout is not lost.
• To achieve this ofcourse the simplest solution would be to just not allow user for any activity when they are not connected to internet, but if system needs that capability the approach we will take is:
  • When user is offline and uploads/records workout, that workout is stored locally in client side offline storage such as SQLLite/local DB.
  • Each workout gets a workoutID i.e. UUID
  • Then when user is back online, it bactches all unsynced workouts to the server.
  • The workoutId along with userId acts as an idempotencyKey, so we will have an uniqueConstraint on those workoutId and userID in table, this avoid duplicates being created.
  • In case if sync fails midway, the client sends same batch again, and sicne we have unique constraint, the already succeed records are ignored

2) Kafka Event delivery Consistency

• How do we ensure messages are not lost when services are down?
  • When kafka reciveces messages and those messages are consumed by workers, those workers might have issues and those message wouild fail and eventually reach max retires and gets lost forever.
  • To ensure this does not happen, we will only commit message as consumed after the message is fully processed, so in case of failures any mid-way messages are dropped and are still in kafka and wehn services are back up they will also process the message again, ensureing no messages are lost
• How do we ensure that when Kafka recieves duplicate events, those duplicate events is not processed twice, leading to wrong stat and goal progress updates.
  • The solution for this is having consumer check eventId.
  • So on consumer side, we store all eventIds processed in Redis.
  • When consumer processes a message:
    • Checks redis -> if event id exists -> skip
    • if event id doese not exist -> message gets processed

How will system handle high read throuput?

• We can have read replicas of DB - so load is divived and system is efficient
• We will utilize Redis as caching strategy which could help in eliminating DB trips.

Failure handling

• What if redis goes down? - Redis is just caching strategy, not source of truth, if redis is down, we fallback to DB, and the lost cache will be eventually build agian naturally
• What if DB fails - we can use read replicas, so failure in one instance doenst not fail entire system. If primary DB goes down, a read replica cna be promoted as primary

Trade offs

• SQL vs NOSql - Prefer SQL here because data here needs relationship and workout data needs to be strongly consistent