System requirements

1. Functional API

Core User Management

• Identity & Authentication:
  • Multi-factor authentication with biometric options
  • Social login with fitness platform integrations (Strava, Garmin, etc.)
  • Role-based access control with trainer/coach relationships
  • Family accounts with parent/child permissions

Activity Tracking

• Workout Recording:
  • Auto-detection of exercise types via motion pattern recognition
  • Voice-controlled workout logging for hands-free operation
  • Form analysis and correction using device sensors
  • Split detection for interval training with automatic segmentation
• AI-Enhanced Insights:
  • Anomaly detection for unusual performance patterns
  • Fatigue and recovery analysis with overtraining prevention
  • Technique improvement suggestions based on motion data
  • Environmental impact assessment (altitude, temperature, air quality)

Goals & Progress

• Adaptive Goal Setting:
  • Smart goals that adjust based on performance trends
  • Multi-dimensional goals combining different metrics
  • Progressive loading recommendations based on training principles
  • Skill-based goals beyond pure metrics (e.g., technique milestones)
• Visualization & Progress:
  • Personalized dashboards with customizable widgets
  • Progress heatmaps showing consistency and intensity
  • Comparative analysis with similar demographic groups
  • Predictive modeling for future performance trajectories

Social Engagement

• Community Features:
  • Interest-based fitness communities with moderation tools
  • Team-based challenges with aggregate performance tracking
  • Coaching marketplace with verification and reviews
  • Content creation tools for sharing workout routines
• Gamification:
  • Dynamic achievement system adapting to user preferences
  • Streak and consistency rewards with recovery allowances
  • Seasonal challenges with themed rewards
  • Skill-based progressions with unlockable features

Special Considerations

• Accessibility & Inclusion:
  • Adaptive interfaces for visual, motor, and cognitive impairments
  • Specialized workout plans for users with health conditions or disabilities
  • Adaptive goals accounting for physical limitations
  • Voice-first interaction model for hands-free operation
• Health Integration:
  • Sleep quality correlation with workout performance
  • Nutrition tracking and macronutrient recommendations
  • Stress management indicators with recovery suggestions
  • Medical data integration with healthcare provider permissions

Edge Cases (With Handling Methods)

• Incomplete Workouts:
  • Implementation: State machine tracking workout phases with cleanup handlers
  • Auto-save checkpoints every 30 seconds during active tracking
  • Manual resume option with clear visual indicators
  • Automatic analysis of partial workouts for useful insights
• Connectivity Issues:
  • Implementation: Queue-based write-ahead logging with conflict resolution
  • Local storage with SQLite and IndexedDB with version vectors
  • Background sync service with exponential backoff retry pattern
  • Prioritized synchronization based on data importance
• Data Conflicts:
  • Implementation: Vector clocks with last-writer-wins for non-critical data
  • Three-way merge algorithm for compatible changes
  • Conflict visualization for user resolution of incompatible changes
  • Audit logging of all conflict resolutions for support
• Sensor Anomalies:
  • Implementation: Kalman filtering for sensor data smoothing
  • Multi-sensor fusion for cross-validation of readings
  • Outlier detection with configurable tolerance thresholds
  • Data quality scoring visible to users for transparency

2. Non-Functional Requirements

• API Response Times:
  • Critical path operations (workout recording): <100ms (p95)
  • Standard UI interactions: <300ms (p95)
  • Data visualization rendering: <1s (p95)
  • Background operations: <3s (p95)
• Throughput:
  • Support 100,000 concurrent active workout sessions
  • Process 10,000 sensor data points per second per user
  • Handle 5,000 writes per second during peak hours
  • Support 20,000 social feed reads per second

Availability & Reliability

• Service Level Objectives:
  • Core workout tracking: 99.99% availability (52 minutes downtime/year)
  • User authentication: 99.999% availability (5 minutes downtime/year)
  • Social features: 99.9% availability (8.8 hours downtime/year)
  • Analytics features: 99.5% availability (43.8 hours downtime/year)
• Failure Handling:
  • Graceful degradation with feature prioritization
  • Automated failover with <10 second recovery time objective
  • Data durability with zero loss for critical user data
  • Geographic redundancy for disaster recovery

Scalability

• User Scaling:
  • Support for 20 million registered users
  • Handle 5 million daily active users
  • Scale to 50 million monthly activities
  • Support 100 million social connections
• Data Scaling:
  • Process 10TB of new data per day
  • Store 1PB of historical data with tiered storage
  • Maintain sub-second query performance at scale
  • Support 100× flash scaling for viral challenges

Security & Privacy

• Data Protection:
  • End-to-end encryption for sensitive health data
  • Fine-grained permission model with purpose limitations
  • Data anonymization for analytics with differential privacy
  • GDPR and HIPAA compliance by design
• Access Control:
  • Attribute-based access control model
  • Just-in-time access provisioning with automatic revocation
  • Behavioral analysis for anomalous access patterns
  • Multi-region data residency controls

Capacity estimation

User Segmentation Analysis

• Power Users (5% of base):
  • 5-7 workouts per week
  • 45-90 minutes per workout
  • 200-500 data points per minute
  • Heavy use of social features
• Regular Users (30% of base):
  • 2-4 workouts per week
  • 30-60 minutes per workout
  • 100-300 data points per minute
  • Moderate social engagement
• Casual Users (50% of base):
  • 1-2 workouts per week
  • 20-45 minutes per workout
  • 50-150 data points per minute
  • Limited social engagement
• Dormant Users (15% of base):
  • <1 workout per month
  • Occasional app opens
  • Minimal data generation
  • Almost no social engagement

Traffic Patterns

• Daily Peak Factors:
  • Morning peak (5-8 AM): 3× average load
  • Evening peak (5-8 PM): 4× average load
  • Weekend mornings: 5× weekday morning load
  • New Year resolution period: 2× normal monthly active users

Storage Requirements

• User Profile Data:
  • Base profile: ~5KB per user
  • Preferences and settings: ~10KB per user
  • Media (profile pictures): ~500KB per user
  • Total for 20M users: ~315GB
• Activity Data:
  • Basic workout metadata: ~2KB per activity
  • GPS route data: ~50KB per hour of tracking
  • Sensor time-series: ~200KB per hour of tracking
  • Media (workout photos): ~2MB per upload (10% of workouts)
  • Projected annual growth: ~120TB
• Social Data:
  • Connection graph: ~500 bytes per connection
  • Feed items: ~1KB per item
  • Comments and reactions: ~100 bytes per interaction
  • Total annual growth: ~15TB
• Analytics & Insights:
  • Aggregated metrics: ~50KB per user per month
  • ML features: ~100KB per user per month
  • Recommendations: ~20KB per user per month
  • Total annual growth: ~40TB

Bandwidth Requirements

• Inbound Traffic:
  • Workout tracking: ~20KB/s per active session
  • Media uploads: ~500KB per upload
  • Social interactions: ~1KB per interaction
  • Peak inbound: ~2GB/s during maximum load
• Outbound Traffic:
  • API responses: ~5KB per request
  • Social feed delivery: ~50KB per feed load
  • Media delivery (via CDN): ~1MB per media view
  • Notifications: ~1KB per notification
  • Peak outbound: ~10GB/s during maximum load

Computational Requirements

• Real-time Processing:
  • Activity validation: ~10ms CPU time per activity minute
  • Goal progress updates: ~5ms CPU time per check
  • Feed generation: ~20ms CPU time per feed request
  • Notification routing: ~2ms CPU time per notification
• Batch Processing:
  • Daily user insights: ~500ms CPU time per user
  • Recommendation generation: ~1s CPU time per user weekly
  • Trend analysis: ~5 CPU-hours per daily global analysis
  • ML model training: ~100 CPU-hours per model update

Enhanced Service Details

Activity Service (Critical Path Component)

• Primary Responsibility:
  • Record, validate, and process user workout data
  • Ensure data integrity and consistent storage
  • Support real-time and batch workout tracking
• Internal Components:
  • Activity Validator: Schema validation and data enrichment
  • Metrics Calculator: Derived statistics computation
  • Route Processor: GPS data analysis and smoothing
  • Activity Repository: Storage abstraction with caching
• State Management:
  • Workout sessions use distributed state with sticky sessions
  • Optimistic concurrency control with version vectors
  • CQRS pattern with separate read and write models
  • Event sourcing for critical workout data
• Scaling Characteristics:
  • Horizontal scaling based on active workout sessions
  • Partition by user ID for data locality
  • Auto-scaling triggered at 70% CPU utilization
  • Specialized instances for data-intensive users
• Resilience Patterns:
  • Bulkhead pattern to isolate failures
  • Retry with exponential backoff for transient failures
  • Circuit breaker for dependent service calls
  • Graceful degradation to core functionality

Recommendation Engine (AI-driven Component)

• Primary Responsibility:
  • Generate personalized workout suggestions
  • Identify relevant challenges and goals
  • Provide adaptive training plans
• Internal Components:
  • Feature Extractor: Processes user history into ML features
  • Model Serving: Hosts trained ML models with A/B testing
  • Recommendation Composer: Combines ML outputs with business rules
  • Feedback Collector: Captures user responses to recommendations
• AI Algorithms:
  • Collaborative filtering for similar user patterns
  • Gradient boosted trees for workout progression
  • Deep learning for motion pattern analysis
  • Reinforcement learning for adaptive plan optimization
• Data Pipeline:
  • Batch feature generation pipeline (daily)
  • Real-time feature serving with feature store
  • Hybrid serving with pre-computed and real-time features
  • Continuous model evaluation with shadow testing
• Scaling Characteristics:
  • Compute-intensive batch processing
  • GPU acceleration for model training
  • Caching of recommendations with TTL-based invalidation
  • Read replicas for feature serving

API Design

RESTful API Hierarchy

Enhanced API Examples

Record Activity with Advanced Metrics

Get Personalized Recommendations

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 enhanced architecture implements a domain-driven design with bounded contexts, clear service boundaries, and specialized components for handling key requirements.

Architecture Components Evolution

The architecture has evolved to include:

• • Domain-Specific Bounded ContextsClear separation of concerns with domain-specific services
  • Independent scaling and deployment for each domain
  • Domain-specific persistence strategies
  • Cross-domain communication via events
  • Traffic Management LayerAdvanced rate limiting with user-specific quotas
  • Request prioritization based on criticality
  • Circuit breakers with cascading failure prevention
  • Adaptive load shedding during peak periods
  • Enhanced Data Processing PipelineStream processing for real-time analytics
  • Lambda architecture for both real-time and batch insights
  • Time-series optimization for sensor data
  • Event sourcing for critical audit trails
  • Specialized Accessibility DomainDedicated services for inclusive fitness experiences
  • Adaptive interfaces based on user capabilities
  • Specialized workout algorithms for different abilities
  • Integration with assistive technologies

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

Key Components of the Recommendation Engine

1. Feature Engineering Pipeline

The feature engineering pipeline transforms raw user data into machine learning features:

• User Feature Extractor:
  • Processes user profiles, historical workouts, and preferences
  • Extracts features like exercise history, frequency, and intensity preferences
  • Implements privacy-preserving techniques for sensitive health data
  • Outputs normalized feature vectors for model consumption
• Temporal Feature Processor:
  • Analyzes time-based patterns in user behavior
  • Extracts cyclical features (daily, weekly, seasonal patterns)
  • Identifies progress trends and plateaus
  • Detects schedule adherence and consistency
• Feature Store:
  • Centralized repository for ML features
  • Supports both offline training and online serving
  • Implements feature versioning and lineage tracking
  • Provides low-latency access with multi-level caching

2. Model Layer

• User Similarity Model:
  • Implements collaborative filtering with embedding-based similarity
  • Creates user embeddings based on workout patterns
  • Uses approximate nearest neighbor search for efficiency
  • Identifies clusters of similar fitness journeys
• Exercise Affinity Model:
  • Predicts user's affinity for specific exercises
  • Balances exploration of new exercises with exploitation of favorites
  • Implements matrix factorization with implicit feedback
  • Incorporates contextual bandits for exploration-exploitation balance
• Progression Optimization:
  • Models optimal progression curves for different exercise types
  • Predicts appropriate weight, intensity, and volume increases
  • Implements reinforcement learning for long-term progress optimization
  • Balances intensity with recovery requirements
• Recovery & Fatigue Model:
  • Predicts recovery status based on workout history and biometrics
  • Implements a fitness-fatigue model with individualized parameters
  • Accounts for sleep quality, stress levels, and nutrition status
  • Provides recovery recommendations to prevent overtraining

3. Recommendation Orchestration

• Recommendation Orchestrator:
  • Coordinates model outputs into coherent recommendations
  • Applies weighted ensemble techniques for recommendation scoring
  • Implements multi-objective optimization (progress, enjoyment, adherence)
  • Ensures diversity in recommendations to prevent monotony
• Business Rules Engine:
  • Applies domain-specific constraints to raw model outputs
  • Enforces exercise safety and compatibility rules
  • Implements personalization preferences (equipment, location, time)
  • Handles special cases like injuries or health conditions
• A/B Testing Framework:
  • Manages controlled experiments for recommendation strategies
  • Implements multi-armed bandit algorithms for dynamic optimization
  • Tracks key metrics (engagement, adherence, progress, satisfaction)
  • Facilitates continuous model improvement

4. Output Generation

• Workout Composer:
  • Creates structured workout plans from recommendation components
  • Balances muscle groups and exercise modalities
  • Implements exercise sequencing algorithms for optimal results
  • Generates appropriate warm-up and cool-down routines
• Explanation Generator:
  • Creates human-readable explanations for recommendations
  • Implements counterfactual reasoning for "why this workout"
  • Highlights expected benefits and progress contributions
  • Adapts explanation detail based on user preferences

Technical Implementation Details

• Scalability Approach:
  • Feature computation uses Apache Spark for batch processing
  • Online feature serving uses Redis with tiered storage
  • Model serving uses TensorFlow Serving with GPU acceleration
  • Recommendation cache with adaptive TTL based on user activity patterns
• Real-Time Performance Optimizations:
  • Pre-computation of base recommendations during off-peak hours
  • Lazy evaluation of personalization aspects at request time
  • Feature caching with invalidation on significant data changes
  • Progressive loading of recommendation details
• Concurrency Handling:
  • Read-heavy workload with immutable recommendation objects
  • Atomic updates to feedback data with optimistic concurrency
  • Background processing of recommendation quality metrics
  • Circuit breakers for dependent service failures

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?