System requirements

1. Functional Requirements Gathering

Core User Actions

• User Management: Register, login, and manage profile information
• Activity Tracking: Record exercises, steps, distance, duration, and calories burned
• Goal Setting: Create fitness goals with specific targets (e.g., run 20km/week)
• Progress Monitoring: View progress against goals, historical trends, and achievements
• Social Interaction: Connect with friends, share achievements, and participate in challenges
• Device Integration: Sync data from wearable devices and fitness sensors
• Notifications: Receive reminders, milestone alerts, and motivational messages

Edge Cases

• Handling incomplete workouts or interrupted tracking sessions
• Managing device connectivity issues and data synchronization conflicts
• Supporting offline workout recording with later synchronization
• Processing retroactive activity logging and goal adjustments
• Handling timezone changes for users who travel frequently

2. Non-Functional Requirements

• Scalability: Support 10 million total users, with 3 million daily active users
• Performance:
  • Activity recording response time < 500ms
  • Dashboard loading time < 2 seconds
  • Real-time tracking updates < 100ms latency
• Availability: 99.9% uptime for core functionality
• Consistency:
  • Strong consistency for user data and activity records
  • Eventual consistency acceptable for analytics and social features
• Security:
  • End-to-end encryption for personal health data
  • Compliance with health data regulations (HIPAA, GDPR)
  • Fine-grained privacy controls for shared data
• Reliability:
  • Zero data loss for user activities and goals
  • Graceful degradation during peak loads
• Observability:
  • Comprehensive logging for user actions and system events
  • Real-time monitoring of service health and performance metrics

Capacity estimation

Traffic Estimates

• Daily Active Users (DAU): 3 million users
• Activities per user: Average 2 activities per day
• Total daily activities: 6 million activities
• API requests per user: ~20 requests per day
• Total daily API requests: 60 million requests
• Peak QPS: Assuming 5× peak-to-average ratio = ~3,500 QPS

Storage Requirements

• User profile data: ~2KB per user = 20GB for 10M users
• Activity data: ~5KB per activity × 6M daily = 30GB/day or ~11TB/year
• Sensor data: ~100KB per hour of activity (20% of users with wearables) = 120GB/day
• Media storage: ~500KB per upload (5% of DAU) = 7.5GB/day
• Total annual storage growth: ~50TB/year

Bandwidth Calculation

• Write traffic: ~160GB/day (~1.85MB/s)
• Read traffic (5:1 read
• ratio): ~800GB/day (~9.25MB/s)
• Peak bandwidth: ~55MB/s during high-traffic periods (6× average)

Memory Requirements

• Cache size: ~20% of daily active user data = ~12GB
• Session data: ~1KB per active session × 3M users = ~3GB

Service Design

Auth Service

• Responsibility: Handle authentication and authorization
• Key Functionality: Registration, login, token management, OAuth integration
• State: User credentials, sessions, tokens
• Dependencies: User Service
• Scaling: Read-heavy, horizontally scalable

User Service

• Responsibility: Manage user profiles and preferences
• Key Functionality: Profile management, settings, metrics storage
• State: User profiles, preferences, settings
• Dependencies: Auth Service, Blob Storage
• Scaling: Read-heavy, cache-friendly

Activity Service

• Responsibility: Record and retrieve user activities
• Key Functionality: Create activity records, store metrics, query history
• State: Activity records, workout data
• Dependencies: User Service, Device Integration Service
• Scaling: Write-heavy during peak exercise hours, read-heavy for history

Goal Service

• Responsibility: Manage user fitness goals and track progress
• Key Functionality: Create goals, track progress, provide achievements
• State: Goals, progress tracking, achievements
• Dependencies: User Service, Activity Service
• Scaling: Balanced read/write, periodic updates

Social Service

• Responsibility: Enable social interactions
• Key Functionality: Friend connections, activity sharing, challenges
• State: Social graph, shared content
• Dependencies: User Service, Activity Service
• Scaling: Read-heavy, graph-based queries

Device Integration Service

• Responsibility: Handle integration with wearables and sensors
• Key Functionality: Device pairing, data synchronization, real-time streaming
• State: Device associations, sync status
• Dependencies: User Service, Activity Service
• Scaling: High-throughput data ingestion

Notification Service

• Responsibility: Manage and deliver notifications
• Key Functionality: Push notifications, in-app alerts, reminder scheduling
• State: Notification preferences, delivery status
• Dependencies: User Service, Goal Service, Activity Service
• Scaling: Burst processing, asynchronous delivery

Analytics Service

• Responsibility: Generate insights from user data
• Key Functionality: Trend analysis, progress reporting, recommendations
• State: Aggregated metrics, statistical models
• Dependencies: Activity Service, Goal Service
• Scaling: Batch processing, compute-intensive

API Design

Key API Details

Record Activity : Log a new fitness activity

POST /activities

Parameters/Body:

- activity_type: String (running, cycling, etc.), required

- start_time: Timestamp, required

- end_time: Timestamp, required

- metrics: Object containing:

- distance_km: Number, optional

- calories: Number, optional

- steps: Integer, optional

- heart_rate_avg: Number, optional

- location_data: Array of coordinates, optional

- device_id: String, optional

Returns:

- activity_id: String, unique identifier

- status: "success" or error code

- achievements: Array of unlocked achievements, if any

Error Handling:

- 400: Invalid input

- 401: Unauthorized

- 500: Server error

Authentication:

- Requires valid user token

Create Goal : Set a new fitness goal

POST /goals

Parameters/Body:

- goal_type: String (distance, duration, etc.), required

- target_value: Number, required

- unit: String (km, minutes, etc.), required

- timeframe: String (daily, weekly, monthly), required

- start_date: Date, required

- end_date: Date, optional

Returns:

- goal_id: String, unique identifier

- status: "success" or error code

Error Handling:

- 400: Invalid input

- 401: Unauthorized

- 500: Server error

Authentication:

- Requires valid user token

Database design

Data EntityStorage SolutionAccess PatternRationaleUser ProfilesPostgreSQLRead-heavy, relationalData has relational integrity needsActivity RecordsMongoDBWrite-heavy, document-basedSemi-structured data with varying attributesSensor DataTimescaleDBHigh-volume time-seriesOptimized for time-series queriesGoals & ProgressPostgreSQLRead/write balancedTransactional updates neededSocial GraphNeo4jGraph traversalOptimized for relationship queriesMedia FilesObject Storage (S3)Write once, read manyCost-effective for binary data

Schema Design

Users Table (PostgreSQL)

CREATE TABLE users (

user_id UUID PRIMARY KEY,

email VARCHAR(255) UNIQUE NOT NULL,

password_hash VARCHAR(255) NOT NULL,

name VARCHAR(255),

birthdate DATE,

height_cm INTEGER,

weight_kg DECIMAL(5,2),

created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,

updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,

preferences JSONB

);

Activities Collection (MongoDB)

{

"_id": "ObjectId",

"user_id": "UUID",

"activity_type": "String",

"start_time": "ISODate",

"end_time": "ISODate",

"duration_seconds": "Number",

"metrics": {

"distance_km": "Number",

"calories": "Number",

"steps": "Number",

"heart_rate_data": [{"time": "ISODate", "value": "Number"}]

},

"location_data": [{"timestamp": "ISODate", "lat": "Number", "lng": "Number"}],

"device_id": "String"

}

Goals Table (PostgreSQL)

CREATE TABLE goals (

goal_id UUID PRIMARY KEY,

user_id UUID REFERENCES users(user_id),

goal_type VARCHAR(50) NOT NULL,

target_value DECIMAL(10,2) NOT NULL,

current_value DECIMAL(10,2) DEFAULT 0,

unit VARCHAR(50) NOT NULL,

start_date DATE NOT NULL,

end_date DATE,

status VARCHAR(50) DEFAULT 'active'

);

Indexing Strategy

• User table: Index on email for login
• Activities collection: Indexes on user_id + start_time, activity_type
• Goals table: Indexes on user_id, status
• Social graph: Indexes on user relationships

Caching Strategy

• User profiles: Cache with 1-hour TTL
• Activity summaries: Cache with 15-minute TTL
• Goal progress: Cache with 10-minute TTL
• Leaderboards and social data: Cache with 30-minute TTL

High-level design

The architecture follows a microservices pattern with clear separation of concerns.

flowchart TD

subgraph Client["Client Layer"]

MobileApp["Mobile Apps\niOS/Android"]

WebApp["Web Application"]

Wearables["Wearable Devices\nWatches/Bands"]

end

subgraph Gateway["API Layer"]

APIGateway["API Gateway\nRouting/Auth/Rate Limiting"]

CDN["CDN\nStatic Assets"]

end

subgraph Services["Service Layer"]

AuthService["Auth Service\nRegistration/Login"]

UserService["User Service\nProfiles/Preferences"]

ActivityService["Activity Service\nWorkout Tracking"]

GoalService["Goal Service\nTargets/Progress"]

SocialService["Social Service\nFriends/Sharing"]

NotificationService["Notification Service\nReminders/Alerts"]

DeviceService["Device Integration\nWearables/Sensors"]

AnalyticsService["Analytics Service\nInsights/Reports"]

end

subgraph DataStorage["Data Layer"]

UserDB[(User DB\nPostgreSQL)]

ActivityDB[(Activity DB\nMongoDB)]

GoalDB[(Goal DB\nPostgreSQL)]

SocialDB[(Social Graph\nNeo4j)]

AnalyticsDB[(Analytics\nClickhouse)]

Cache[(Cache\nRedis)]

BlobStorage[(Media Storage\nS3/Blob)]

TimeSeriesDB[(Sensor Data\nTimescaleDB)]

end

subgraph Infra["Infrastructure Layer"]

MQ["Message Queue\nKafka"]

PushNotifications["Push Notification\nSystem"]

Monitoring["Monitoring & Logging"]

ML["ML Pipeline"]

end

%% Client connections

MobileApp --> APIGateway

WebApp --> APIGateway

MobileApp --> CDN

WebApp --> CDN

Wearables --> DeviceService

%% API Gateway routing

APIGateway --> AuthService

APIGateway --> UserService

APIGateway --> ActivityService

APIGateway --> GoalService

APIGateway --> SocialService

APIGateway --> NotificationService

APIGateway --> DeviceService

APIGateway --> AnalyticsService

%% Service to database connections

AuthService --> UserDB

UserService --> UserDB

UserService --> BlobStorage

ActivityService --> ActivityDB

ActivityService --> TimeSeriesDB

GoalService --> GoalDB

SocialService --> SocialDB

SocialService --> BlobStorage

NotificationService --> Cache

DeviceService --> TimeSeriesDB

AnalyticsService --> AnalyticsDB

%% Cache connections

UserService --> Cache

ActivityService --> Cache

GoalService --> Cache

SocialService --> Cache

%% Async connections

ActivityService --> MQ

GoalService --> MQ

DeviceService --> MQ

MQ --> AnalyticsService

MQ --> NotificationService

NotificationService --> PushNotifications

AnalyticsService --> ML

ML --> AnalyticsService

Request flows

Activity Recording Workflow (Write Path)

1. User completes workout on mobile app or with wearable device
2. Client app collects activity data (type, duration, distance, etc.)
3. Client sends POST request to /activities endpoint
4. API Gateway authenticates and routes to Activity Service
5. Activity Service validates data and stores in Activity DB
6. Activity Service publishes "activity.created" event to Message Queue
7. Activity Service returns success response to client
8. Asynchronously:
   • Goal Service updates relevant goal progress
   • Notification Service checks for achievements
   • Analytics Service updates user statistics
   • Social Service updates feed (if sharing enabled)

Activity Feed Retrieval Workflow (Read Path)

1. User opens app dashboard
2. Client requests activity feed via GET /activities/feed
3. API Gateway authenticates and routes to Activity Service
4. Activity Service checks cache for recent data
5. If cache miss, Activity Service queries database
6. Activity Service formats data and caches results
7. Response returned to client for display

Detailed component design

flowchart TD

A[User Device] -->|"Activity Data\n(JSON Payload)"| B[Data Ingestion API]

subgraph Validation["Validation Layer"]

B --> C[Schema Validator]

C --> D{Data Valid?}

D -->|No| E[Error Handler]

D -->|Yes| F[Data Normalizer]

end

subgraph Processing["Processing Layer"]

F --> G[Metrics Calculator]

F --> H[GPS Processor]

G --> I[Enrichment Service]

H --> I

I --> J[ML Calorie Estimator]

end

subgraph Storage["Storage Layer"]

J --> K[Activity Writer]

K --> L[(Activity DB)]

K --> M[(Time-Series DB)]

K --> N[Event Publisher]

end

subgraph Consumers["Downstream Consumers"]

N --> O[Message Queue]

O --> P[Goal Updater]

O --> Q[Achievement Processor]

O --> R[Analytics Engine]

O --> S[Social Feed Updater]

end

E -->|"Retry or\nError Response"| T[Client Error Handler]

T --> A

The Activity Processing Pipeline is a critical component that handles high-volume workout data:

• • Data Ingestion LayerAccepts data from mobile apps and wearable devices
  • Handles both real-time streaming and batch uploads
  • Implements rate limiting and request validation
  • Uses buffers to handle peak load periods
  • Processing and EnrichmentNormalizes data from different sources into standard format
  • Calculates derived metrics (pace, intensity zones)
  • Processes GPS data for route visualization
  • Applies machine learning for accurate calorie estimation
  • Concurrency HandlingUses optimistic concurrency control for activity updates
  • Implements idempotent operations to handle duplicate events
  • Employs distributed locking for critical sections
  • Ensures exactly-once processing semantics
  • Error HandlingCircuit breaker pattern for external service calls
  • Dead letter queue for failed processing attempts
  • Automated retry with exponential backoff
  • Fallback mechanisms for degraded service operation

Trade offs/Tech choices

Key Technology Decisions

MongoDB vs. PostgreSQL for Activity Data

• MongoDB advantages: Schema flexibility, easier horizontal scaling, better write performance
• PostgreSQL advantages: ACID compliance, better joins, mature tooling
• Decision: MongoDB chosen due to:
  • Variable activity types with different metrics
  • High write throughput requirements
  • Need for flexible schema evolution
  • Less need for complex joins across activity data

Kafka vs. RabbitMQ for Messaging

• Kafka advantages: Higher throughput, better durability, event replay capability
• RabbitMQ advantages: Simpler operations, more routing options
• Decision: Kafka chosen due to:
  • Need for event sourcing patterns
  • High durability requirements for activity events
  • Ability to replay events for system recovery
  • Better scaling for projected message volume

Failure scenarios/bottlenecks

Key Performance Optimizations

• • Activity Data Ingestion (High-Volume Upload Times)Bottleneck: Concurrent workout uploads after peak exercise hours (5-7 PM)
  • Solution: Auto-scaling ingestion workers, request batching, write sharding
  • Expected Improvement: Handle 5× normal load during peak times without degradation
  • Social Feed Generation (Popular Users)Bottleneck: Feed computation for users with many followers
  • Solution: Pre-computed feeds, materialized views, fan-out-on-write pattern
  • Expected Improvement: Reduce feed generation time from seconds to milliseconds

Future improvements

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