Loading...
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...\
1) Post /workouts
{
activityName:"',
time,
activityStatus:"",//inprogress completed
}
2) GET /workouts -> Returns the history of activites and basic stats
3) POST /sync -> Used to sync across devices
{
clientId:""
}
4) /stats/:activityId -> Response
{
ActivityName:"",
timeTaken:"",
DistanceCovered
}
Returns the stats for a particular activity Dependes basaed on the activity
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.
For rate limiting we can add a api gateway which handles authentication, rateLimiting using sliding window counter.
Each client makes a call to workout service which stores the workout details in a nosql database, we are sticking with database like nosql because the activities are write heavy based on the distance travelled we will not sent continous events to service we can buffer them locally and then sent. For viewwing history we can again query sql database to get the history of the events and perofmr agregration on top of it. For sync we can call the sync service which based on activity id will sync the remaining activities we will be using timeUUid for each activities and read the last offfset of the client and read the entries which are not there in the client from the server.we will use kafka for managaing traffic spkies and large uploades to ensure high availability and ensure uplods are not affected we will partiion it based on activityId so it will help us to rank users of single activity. Some users prefer to train in some remote areas where connectivity is less so the client will not be able to make call to server to upload it's data to handle this we can store the activity records locally in a sqlLite database andriod offeres room databse to handle these operations and whne user is connected we will send these events to the server.To manage temprorary lag we can make the system not a real time by adding two - three seconds lag although user will get the feeling that activity is happening at rel time but ehy are not
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
For rate limiting we can add a api gateway which handles authentication, rateLimiting using sliding window counter.
Each client makes a call to workout service which stores the workout details in a nosql database, we are sticking with database like nosql because the activities are write heavy based on the distance travelled we will not sent continous events to service we can buffer them locally and then sent. For viewwing history we can again query sql database to get the history of the events and perofmr agregration on top of it. For sync we can call the sync service which based on activity id will sync the remaining activities we will be using timeUUid for each activities and read the last offfset of the client and read the entries which are not there in the client from the server.we will use kafka for managaing traffic spkies and large uploades to ensure high availability and ensure uplods are not affected we will partiion it based on activityId so it will help us to rank users of single activity. Some users prefer to train in some remote areas where connectivity is less so the client will not be able to make call to server to upload it's data to handle this we can store the activity records locally in a sqlLite database andriod offeres room databse to handle these operations and whne user is connected we will send these events to the server.To manage temprorary lag we can make the system not a real time by adding two - three seconds lag although user will get the feeling that activity is happening at rel time but ehy are not
before inserting in databse we will check if the uuid for the same activity already exisitis if it does then we don't insert else we do
For large and slow uploads we can use chunking we can chunk the data in localsql lite and upload it htrough multiple api calls and we can get a hash of each uploaded part then we finally responsd with hash of each part
For making sure to handle out of order gps data we can attach a counter to each gps entry to ensure they are in order for that we can use redis we can increament the counter of redis for each activityId once activity is completed we can delte the counter