System requirements

Functional:

• add/remove workout
• set/remove goal
• get progress

Non-Functional:

• scalable
• reliable
• evolvable

Capacity estimation

• 100 million users
• 10% DAU
• 2 daily workouts per daily user
• .1% users set/remove goals
• 1 progress check per daily user
• workout size = 16Bytes from 4B (type) + 4B (start time) + 4B(end time) + 4B(calories)
• Daily new data: 1e8 * 0.1 DAU * 16B = 16e7B = 16e4KB = 160MB daily.
• Year load: 160MB/day*365day=16*3.65*1e3MB = 16*3.65 GB ~ 60 GB.
• Request per second: 1e8users*.1active*3requests/day=3e7req/d = 347rps average. ~1K rps peak

API design

• /workouts - PUT http method
  • params: type(int), start_time(int), end_time(int), calories(int)
  • response: workout_id
• /workouts/id - GET http method
  • param: id
  • response: workout's data (JSON)
• /workouts - DELETE http method
  • param: id
  • response: success/failure
• /workouts - GET http method
  • response: workout ids list (json)

• /goals - PUT http method
  • params: type(int), start_time(int), end_time(int), calories(int)
  • response: goal_id
• /goals - GET http method
  • response: goal ids list (json)
• /goals - DELETE http method
  • param: id
  • response: success/failure
• /goals/id - GET http method
  • param: id
  • response: goal's data (JSON)

Database design

User data: SQL DB

Tables:

Workouts

• id: PRIMARY KEY BIGINT
• user_id: FRGN KEY to Users, Partition Key
• start: datetime
• end: datetime
• type: INT
• calories: INT

Goals

• id: PRIMARY KEY BIGINT
• user_id: FRGN KEY to Users
• target: INT

Users

• id: PRIMARY KEY BIGINT
• email: VARCHAR
• name: VARCHAR
• password: hash (SHA2_512) BINARY(64)

High-level design

• Client's mobile phone App
• Service's public REST endpoints
• Service Load Balancer
• Backend Servers
• Relational DB for user's authentication
• Key/Value datastore for workouts

Request flows

Put a workout: The client sends a PUT request to /workouts with a json payload with the parameters. The request gets routed and arrive to the API Gateway, which forwards it to the LoadBalancer. The LB chooses a server and forwards the request. The server verifies that the client is authenticated, verifying the auth cookie. If not good, the servers sends a response unauthorized. If good, the server creates a new workout entry in the key-value store (e.g. dynamo or mongodb), and replies with success.

All other flows are similar.

Detailed component design

The APIGateway receives the HTTP requests, performs basic verification such as DoS attacks, and routes the requests to the LB. A load balancer keeps a list of active servers, and chooses a server based on an algorithm.

The cloud service (like EC2) monitors the health and load of the servers scales up or down (creating new instances or shutting down some) if the load is too high/low or a server is unresponsive.

The key-value store is horizontally scalable and it is good on write requests.

Trade offs/Tech choices

The solution uses 2 database types. While this adds complexity, it fits different use cases for different data access and scalability patterns. The users data is not too large and requires high consistency, thus a relational db is better suited for that. For workouts and goals, a key-value store allows for very high write and reads, scaling horizontally, which is good for the not relational workout data while having eventual consistency.

Failure scenarios/bottlenecks

A

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?