Requirements

Functional Requirements:

• Log workouts
• View history & basic stats.
• Sync across devices.

Non-Functional Requirements:

• App should be funtional
• Latency should be low < 100 ms so response should time should be low p95
• System should handle peak load and Scalable when needed like 1st jan etc
• System should be available without a down time
• Syncing can be eventual consistency
• Read should be constant across the devices after a time.
• Make sure data is not lost and write are progragate handle duplicate records.

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

post /activities(user, activity)

POST /activities/bulk 

get user/{id}/activites

get /activities/{activity_id}

notification post/notficications get/notificatoin

message queu

Goals /user/{id}/goals

Goals /user/{id}/stats

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

• 100 million user
• Daily active users can be of 10 million
• 10 million every day
• qps 100 peak qps 500
• sycn fanout architecture to sycn accross devices

Calculateion -

user id 16 bytes, workout type- 20 bytes , duration - 8 bytes, caloires bured 4 bytes,distance 0 8 bytet, heatrate- 4 bytest, timestamp 8 byte -- 200bytes

2kb * 1m== 2gb per day - 700gb per year

peak 10gb per day

5 Year 3.5 tb

Let me try to put down things

1. User can login via any watch, mobile app, web
2. Api gateway will manage routing,authentication and etc
3. We can keep a rate limiter for handling request and the same way we will make sure that there is a burst setting that after a certain limiti like 10 per minute we send 429 or basically slow down message
4. During high load we will have more service of activity service and etc we can keep load balancer for each service too when expanding it
5. Activity service will be use message queue for entry of workload and use object storage for s3 storage for files and all.
   1. here we can use chunking for uploads
6. We will also have time series for histroy based
7. Main data will be stored in Main database which will keep a master slave architecture
8. Redis will suffice the stats service and we will keep the 80:20 rule for here too
9. If the app is offline we will store that in local storage and when the user comes to online we will add that
10. We will keep the cache workout data for selceting if user is offline
11. Message queues will be there for using and will we use event streaming to store in analytical service
12. After update or delete entry we will delete it and update the cache .
13. The flow will be userId and starttime will be used for primary entry and if any things needs to be update we will put last updated time
14. Goal service will be used to track user goal
15. Integration service will be useful for syncing the data across device once the data base is populated we can have a pub sub pattern
16. For bult import we can have a csv file pattern and it can be send via queue to service via bulk api. Worket process files asnyncrohoulsy and storea data
17. From we can call the analystics to store data based on each day once the record is updated and can then update the db and cache for the same value
18. If any service fails we have circuit breaker to check the service incase it failes we try to fix it and at the same time have the data read from the last replication , if that is also not available we let the other service do the job
19. Flow Activity Service → Event Queue → Analytics Service → Analytics DB
20. When ever new activity will come it will create an event, activiy create, updated,deltered - via kafka/sqs + sns , anaylics service will substribe to this mertics\
21. we will only update relevenat nbucket user-date, user-date-activity
22. Daily serciwill be udpated to a fast store could be anything like a separte DB service
23. if any service is updated or delted we can use eventid+ versiom/ipdate AT tso that we handle idempotency.
24. After analytice update the daily summary it can either invalidate the cahce or write a fresh value in redis

Main Database (OLTP)

1. Stores user activity, goals,metadata
2. primary- replica architecutue for high availabilty
3. primary handles write replioca handles read
4. userId,activituId,starttime,duration,calories

Time series Database

1. Stores historical fitness metrics like steps, heart rate
2. Optimized upload used for reliability and handling large files
3. activity service- main DB - time servies DB (steps ,heaart rate
4. Object storage- workout images, activiy export, GPS (outdoor)
5. Daily step count and calories will go in analytics

Goal serive.

1. User goal activities ( steps/day, calories
2. tracks progress based on activity day
3. user cached and aggregared data for fast reposnse

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

Idempotency -

1. We will handle the fucntion via event streaming - we will have a combination of event id with version or last updated at if both have same we are going to take the latest data.

large upload-

1. Large upload like bulk will be done sync via batchjing the user can see progress
2. we will let the worker threads work on it and we can use http polling to get the fresh updates of process once it is done we can send the notification to the user