Requirements

Functional Requirements:

• User is able to log their workouts - manually or auto pushed via fitness watches or native companian app on the watch.
• User is able to set goals
• User is able to track their goals
• User is able to view hisotry and basic stats

Assumptions:

• 100M daily active users.
• 10% record at least one workout daily.
• 5 read requests per DAU per day.
• Peak traffic is approximately 5× average traffic.

Writes

• 10M workouts/day.
• Average write QPS = 10M / 86,400 ≈ 116 QPS.
• Peak write QPS ≈ 580 QPS.

Reads

• 100M × 5 = 500M reads/day.
• Average read QPS = 500M / 86,400 ≈ 5,800 QPS.
• Peak read QPS ≈ 29,000 QPS.

Storage

Assume an average persisted workout record of approximately 1 KB, excluding indexes and replication.

• 10M × 1 KB = approximately 10 GB/day.
• Approximately 3.65 TB/year of raw workout records.
• 1B records ≈ 1 TB of raw data at this record-size assumption.

These estimates suggest that reads dominate traffic, so caching, indexed history queries, and read replicas are valuable.

Non-Functional Requirements:

• Workout data should be highly consistent ensuring no data loss while goal and stat data is acceptable as eventual consistent updating after workout creation/updates
• Low latency - system should be quick enough to move through traffic without any abnormalities especially during high traffic times such as morning or late evenings
• Highly scalable - should be able to handle 1B unique workout records
• High read throughput - system should be able to handle read traffic efficiently
• Workout records should be idempotent ensuring no two duplicate records are created

Data entities:

User

Id

Name

Email

Workout

Id - PK, also idempotent key

userId - partition key

Source - App/Fitness Watch/ Native app

Type - Strength/Cardio

Intensity

TimeTaken

CaloriesBurned

CreatedAt

Goal

Id - PK

UserId - Partition key

GoalWeight

CurrentWeight

Type - lose, gain

PercentComplete

CompletedAt

CreatedAt

UpdatedAt

UserStats

id

UserId - Partition key

totalWorkout

TotalGoals

GoalsCompleted

CurrentWeight

CurrentHeight

APIs

Create workout

POST /{user_id}/workout

req - {

id - idempotent key

source,

time,

intensity,

type

}

res - { id }

Batch-sync offline workouts

POST /users/{userId}/workouts/batch

Accepts a batch of client-generated workout IDs and workout records. Each record is independently idempotent, so retrying a partially successful batch is safe.

Create Goal

POST /{user_id}/goal

req -

{

id,

type,

goalWeight

}

Get user stats

GET/{user_id}/stat

response -

{

userId,

totalWorkouts,

totalGoals,

GoalsCompleted,

GoalsInProgress,

}

//fetch a workout

GET /{user_id}/workout/{workout_id}

Res - Workout

Get workouts history

Get /{user_id}/workout?filters=

res - workoutList

High-Level Design

API Gateway

Acts as the entry point for all client requests.

Responsibilities:

• Authentication (if required)
• Rate limiting - token bucket per API key/IP to prevent abuse and control write traffic.

Load Balancer

Distributes traffic across multiple instances of the Read and Write services to improve scalability and availability.

Workout Service:

Responsibilities:

• Create workouts
  • Uses idempotency key to ensure duplicate records are not created
• Fetches workout history
  • First page of history is stored in Redis, so if cache hit, return immediately
  • If cache miss, get data from DB, stgore in Redis and return.
• Publishes workout created event to kafka
• Also consumes WorkoutFetched event from kafka to create the fethced workout from devices.

Goal Service:

Responsibilities:

• Creates goals
• Fetches goal
• Fetches goal progress
  • Used redis here to fetch goal progress, if found return from redis,if cahce miss go to DB.
• Subscribes to the workout created event and updates the goal progress accordingly.

Stats service:

Responsibilties:

• Fetches user basic stats.
• Flow:
  • Check Redis: if hit, return immediately
  • If miss, fetch from DB table UserStats
  • Store it in redis
  • Return data
• Subscribes to the workout created event and updates the stats in redis if present and as well as in DB.

Redis:

• Acts a cache layer, use to cache frequently accessed data.
• We will store:"
  • User stats : userId -> stats
  • Recent workouts : last 10-30 workouts
  • Goal progress
  • First page of workout history
• All the above is shown is user dashboard, so all of this will be cached.
• TTL-based + cache-aside pattern

Device Tracker Service

• Registers user device when to app, when user connects the device to our system.
• A background service running periodically that Fetches any newly recorded workouts from the registered device
• Publishes the WorkoutFetched event to kafka

Kafka

• Carries workout-created and workout-updated events.
• Uses userId as the partition key to preserve event order for a user within a partition.
• Decouples workout ingestion from goal and stats processing.

SQL Database

• Source of truth for workouts, goals, and statistics.
• Unique constraints and transactions provide durable writes.
• Indexed queries and partitioning support history reads and growth.

Deep Dive 1: Offline Sync and Idempotency

The application must support recording workouts without a network connection.

1. The client generates a UUID for each workout and stores it in local persistent storage.
2. When connectivity returns, the client uploads unsynced workouts in batches.
3. The server enforces a unique constraint on (userId, workoutId).
4. If the same workout is submitted again, the server returns the existing result rather than inserting a duplicate.
5. If a batch fails halfway through, the client retries it. Already committed records are recognized, while missing records are inserted.

For device imports, we additionally deduplicate using the provider's workout ID. This prevents the same workout from being imported repeatedly during polling or webhook retries.

If the server is unavailable, the client retains unsynced workouts and retries with exponential backoff.

Important: The server acknowledges a workout as saved only after the workout record and its outbox event have committed successfully.

Deep Dive 2: Reliable Kafka Event Delivery

There are two separate failure scenarios to handle.

A. Prevent losing events between SQL and Kafka

A naive implementation writes the workout to SQL and then publishes an event. If SQL commits but Kafka is unavailable, the workout exists while the downstream event is lost.

Use the transactional outbox pattern:

1. Begin a SQL transaction.
2. Insert the workout.
3. Insert a WorkoutCreated event into an outbox table.
4. Commit both changes atomically.
5. A background publisher reads pending outbox events and publishes them to Kafka.
6. Mark events as published after successful delivery.

If publishing fails, the publisher retries. It may publish an event more than once if it crashes after Kafka accepts the event but before marking the outbox row as published. Consumers must therefore be idempotent.

B. Prevent duplicate consumer effects

Kafka may redeliver messages when a consumer crashes or its offset has not been committed.

Each event has a stable eventId. The consumer:

1. Begins a database transaction.
2. Inserts the event ID into a ProcessedEvents table with a unique constraint.
3. If the event ID already exists, it skips the business update.
4. Otherwise, it applies the stats or goal update.
5. Commits the transaction.
6. Commits the Kafka offset after successful processing.

The processed-event record and business update must be in the same transaction. This prevents a crash from recording an event as processed without applying its effects, or applying its effects without recording it as processed.

This provides reliable, effectively-once business processing for each consumer's database transaction, rather than relying on end-to-end exactly-once delivery.

Deep Dive 3: Read Scalability and Caching

Read traffic is much higher than write traffic, so we optimize dashboard and history access.

Read path:

1. Check Redis for the requested data.
2. If there is a cache hit, return it.
3. If there is a cache miss, query the database using an appropriate index.
4. Populate Redis with a TTL and return the result.

Caching strategy:

• User stats: userId → stats
• Goal progress: userId + goalId → progress
• Recent workouts: userId → recent workouts
• First page of workout history: cache only if the access pattern justifies it.

When authoritative data changes, invalidate or update affected cache entries after the database transaction commits. TTLs provide an additional safeguard against stale cache entries.

For stronger read-after-write behavior, route a user's immediate post-write read to the primary database or use a consistency mechanism that accounts for replica lag.

Database scaling:

• Add read replicas for read-heavy traffic.
• Use indexes and cursor pagination for history queries.
• Partition workout records by an appropriate combination of user and time as the dataset grows.
• Monitor hot partitions, replication lag, cache hit ratio, and database saturation.

Trade-offs

SQL vs. NoSQL

I would start with SQL because we need durable transactional workout writes, uniqueness constraints for idempotency, and well-defined consistency for goals and stats.

At this scale, I would add indexing, partitioning, read replicas, and possibly sharding as needed. A distributed NoSQL database could be appropriate if access patterns and throughput requirements eventually justify its trade-offs, but it is not automatically better for storing a billion records.