Requirements

Functional Requirements:

• Log workouts
• View history
• Weekly checkin time, monthly checkin time.
• Sync across devices.

Non-Functional Requirements: （Sscalop）

• Scalable: The whole system can be scaled up smoothly to handle more request.
• Security: Prevent ddos. include WAF.
• Consistence: Eventually consistency. View data from different devices, eventually same. Make sure there isn't duplicated write. All the records should be stored.
• Availability: High Availability. User can always fetch the data without any down time.
• Latency: get request should be P99: 100ms, P80: 200ms.
• Observability: Monitor :latency, errors, traffic, saturation (cpu usage, memory ect)
• Peak: write request: 100k qps. Get request 1M qps. 10 Million active users

API Design

Write workout log:

1. Post API /log/create?userId=string CreateWorkOutPlan(startDate: Int, EndDate: Int, Log: List<String>): true
2. Patch API /log/userId: Update (startDate: int, EndDate: int, Log: List<String>);

View workout log:

1. GET API /log/userId: Get(StartDate: int, EndData: int): Json Map: <date: List<String>>

View Stats:

1. Get api/stats/weeklyCheckin?userId=xxx: get(): int. Return the days user weekly check in the workout.

High-Level Design

1. Client: all type of device to send rest api.
2. CDN: I'd assume most of request is get request. To review the workout logs or stats. These can be cached at CDN. I also don't think workout log will be updated quit often. A user updates the log most likely will be per week or month. This also prevent the DDOS. CDN can detect bot request.
3. Api gateWay: This can use as rate limiter, also the auth for each api token. Then forward the quests to the right server.
4. LB. When the peek comes, it distributes the request to different replicate.
5. We have 3 big servers if needs.
   1. Log write manage server
   2. Log read manage server
   3. Status read server.
6. Read servers have the origin caches which stores the cdn(cache miss) records
7. We have a kafka in place when a workout log status has been change, the write service will send a topic to kafka. Each aggregation consumer can consume the message and do the aggregation and calculation.
8. 10 million active users. One DB per region, should be enough.

Detailed Component Design

1. Log DB -- this can be a relationDB.
   1. User table : userId(uuid), gender, name, age, body type, weight, high.
   2. Log table: logId(uuid), userId(uuid), start date(timestamp), end datetimestamp), workoutname: string, description: text, status: string(done/todo), times: int)
   3. Index log table, userId, logId. start date, end date, status.
2. Stats DB -- nosql (key-value)
   1. User Id, year-week(string). total. key is userId-year-week
3. Cache:
   1. CDN: I don't think user would update the workout log that often. Max once a day. So we can set the ttl is 24 hours, and stale-revalidation is 30s & we update the record when there is a write request comes. Most user would just read today's workout log. So the CDN, just store the today's ttl.
   2. Read log cache: it can be ttl 1 min cache. If the cache doesn't have the record. The read server would read from db and write to cache. If there isn't record return 500.
   3. Read status cache: it can be ttl weekly cache. The status doesn't update as often requests.
4. Kafka: If there is a check in write server will post a top to kafka, and kafak will pass the event to the consumer worker and the worker will update the db, based on the week and then update the total time.

Failure scenarios/bottlenecks

• If write server is down, or error. We can send the request to a retry worker and retry for 5 times.
• The write server could have a high peek. We could adding a message queue.

Future improvements

1. User doing workout offline