System requirements

Functional:

User is able to record the workouts

User set goals based on pair of frequency and workout

Dashboard to check progress, based on workout type and ratio of completion at current time interval (day or week)

Some other things like intake/calories tracking, sharing will not be covered

Non-Functional:

High availability: users should be able to access the app whenever they want

Low latency: users should get immediate display when track progress

Durability: once workouts are uploaded, data is not lost

Consistency: eventual consistency since the data freshness is not critical

Capacity estimation

Total users: 10 millions

DAU: 1 millions

QPS:

• record activities: 2 workouts per day per user ~ 2 millions requests
• set goal: 50,000 users set new goals
• check progress: 10 times per day per user ~ 10 millions requests
• 12 millions / (3600 * 24) ~= 120 QPS average
• Peak QPS: 500 QPS, for example after working hours

Storage:

• Goal: 50,000 * (user, workout type, frequency -> 16 bytes) = 800 kb per day -> 800kb * 365 ~= 200MB per year
• User: 10 millions users -> 1kb * 10millions ~= 10GB
• Activity records: calories + workout type + timestamps + metadata -> 1kb * 2 millions per day ~= 2GB * 365 ~= 700GB per year
• if we keep it for 5 years, then we're looking at a 3.5TB storage

API design

• POST /activity (type, calories, timestamps)
• PUT /goal (calories)
• GET /progress?day={day} -> {calories burned, goal}
• GET /activities?day={day}

Database design

Typically, we're not looking at complex calculation, and thinking about 700GB per year scale and write heavy at peak hour, noSQL for example Cassandra is a good choice with flexibility and Horizontal scalability.

Collections are as the class diagram

High-level design

The system typically focuses on two type of use cases, thus three key components has to be separate services: ActivityService, GoalService, UserService, data are persistent into Cassandra while cache can be used to improve all services' performance, please see High-level diagram

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Detailed component design

1. Essentially for low latency, cache system should be included
2. we should have a local cache in UserService for example use LRU algorithm for fast access to active users, let's say we need the information about 10,000 DAU in cache, which will occupies 100,000 * 100bytes -> 1MB, pretty fairly small to fit all into cache
3. A local cache/external cache system for Activity Service which allows users to view the history of their recent activities, same LRU here
4. A cache for GoalService is essential for goal fast tracking, as a bit strong consistency is required, we can do write-through and read-through combination here
5. Within ActivityService
6. let's have a reader service that reads all the events and load them into a messaging system
7. we can use a pub/sub messaging system here, as latency here is more critical than throughput, we can go with push-based RabbitMQ
8. So multiple processing service can consume the events in parallel which guarantee some level of throughput plus push-based partitioned messaging system promote low latency
9. a writer service will read from the queue and persistent those activities into database and also into cache system
10. GoalService can subscribe to the same topic to increment the progress for the goal
11. ApiGateway is where we could do load shedding, rate limiting, WAF, SSL termination, authentication, authorisation, for example we may have membership policy
12. Datastore
13. For the UserService, GraphDB is a good fit which support the feature such as users following each other
14. For the activityService
15. CassandraDB is good since we're looking at large scale, and very likely will be queried based on time range, partitioned by time is a good practice for the use case
16. ObjectStorage such as AWS S3 can be used to store archived data for example older than 5 years or softDeleted data older than 1 year
17. For the GoalService, CassandraDB is very well suited, since wide-column nature allows GoalService to store the set goal and progress in the same table
18. Replications should be equiped for all Datastores
19. We can do a batch processing per day for users for progress tracking in-memory

Trade offs/Tech choices

• GraphDB is good for manage social app, manage relationships at any scale
• CassandraDB with wide-column nature is good fit for flexible schema and large scale where we look at 700GB per year
• RabbitMQ is low-latent push-based messaging system which can help the processing in time, also its pub/sub support can allow ActivityDbWritter and GoalService process the same batch of events

Failure scenarios/bottlenecks

The ActivityService may fail at any stage, for example that it successfully publish into the queue, and fail the db writer, we can configure the retry policy to the queue and allows the DB writer to process the event at later time, up to a max retry times, we can use a DLQ to store the events for later manual processing

We can setup regional server instances, even regional load balancers in front of all service clusters in any region, on one hand, it improves the performance that edge servers serves requests quicker, and on the other hand, it brings high availability, that can failover request to other regions

Future improvements

we can have a sequence batch process at any tier an point of the system to improve the throughput, also monitoring service should be integrated to generate metrics for all the instances about resource utilisation so that services can scale more efficiently, also enabling logs helps to do any PIR. Annual review to check the system against hundreds of questions to find operational gap as system are varying along the time since load may change, new features may be introduced, and security patches.