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
• Target 99.9% availability (or 99.95% if you want to sound stronger).
• Syncing can be eventual consistency
• Read should be constant across the devices after a time.
• Cross-device sync is eventually consistent, but user should see the same data on all devices within < 1 minute (sync SLA).”
• All activity write APIs are idempotent using (userId, activityId) or (deviceId, eventId) as a unique key. Retries won’t create duplicates.”
• We need P95 reads <100ms, 99.9% availability, scalable for peak spikes, eventual consistency with <1 min cross-device convergence, durable writes with no data loss, and idempotent ingestion using unique event IDs to prevent duplicates.”

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) return success

POST /activities/bulk  return tracker inProgress/success/error

get user/{id}/activites return list of activites

get /activities/{activity_id} return activity requested

notification post/notficications get/notification

message queue handles asycn process DB operation

get Goals /user/{id}/goals -- return goals like weight, step count,

get stats /user/{id}/stats -- return stats like workout done ,calories counted

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

How will you handle out-of-order or noisy GPS data?

. GPS data - we will store raw gps data but won't rely on it

1. we will have timestamp and sequences and will reorder
2. we will also remove any glitches like too much sppeed and keep an avg

Encoding routes- i won;t store the full latitude and longitude i will store the differnce and try to convert it into stirng and then use some library like google poly line, basicallly store the first lat and then just store the diference ,

Have you considered how to ensure async enrichment won't block user interactions :-

this will be fire and forget,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\

How will you handle offline data buffering and merging on reconnect?

We will userID activity id stored in local storage and event will have to replay to sync

What approach will you take to ensure backlog/replay is safe?

Safe replay by using an outbox on the client 0-> unique eventid,activityy id , version/updaredby

on reconnecte we will process them in order and server will rpocess them idempotently if there is stale event we will miss it

also sends per event acknowledgmen so client can delete it after that