System Architecture
Mirobody Health is built with a modular, layered architecture that separates concerns and enables easy extensibility.Core Components
API Layer
FastAPI-based REST API for external integrations
Provider System
Pluggable OAuth integrations for health devices
Data Pipeline
ETL pipeline for health data transformation
AI Services
Multi-provider LLM integration for chat
MCP Protocol
Model Context Protocol for AI agents
Storage Layer
PostgreSQL and Redis for data persistence
Architecture Layers
1. API Layer
The API layer provides RESTful endpoints for all system interactions:- Async request handling with FastAPI
- Automatic API documentation (OpenAPI/Swagger)
- CORS support for web clients
- Request validation with Pydantic models
- JWT-based authentication
2. Provider System
Pluggable architecture for health device integrations: Components:BaseThetaProvider: Abstract base class for all providersThetaDataFormatter: Standard data transformation utilitiesThetaTimeUtils: Timezone and timestamp handling- Provider-specific implementations (Garmin, Whoop, etc.)
3. Data Pipeline (TBD)
ETL (Extract, Transform, Load) pipeline for health data:- Pull: Fetch data from vendor API
- Save: Store raw data in database
- Format: Transform to standard format
- Upload: Push to Mirobody platform
4. AI Services
Multi-provider LLM integration for intelligent health insights:- Provider-agnostic interface (coming later)
- Context management for conversations
- Tool calling for health data access
- Session history persistence
5. MCP Protocol
Model Context Protocol support for AI agent integration:- JSON-RPC 2.0 interface
- Tool discovery and execution
- Resource management
- Agent orchestration
6. Storage Layer
Dual storage system for different data types:- PostgreSQL
- Redis
Used for:
- User credentials (encrypted)
- OAuth tokens and refresh tokens
- Raw health data (JSONB)
- Provider configurations
- Session history
Data Flow
OAuth Authentication Flow
Health Data Synchronization
Design Patterns
Plugin Architecture
Providers are discovered and loaded dynamically:Factory Pattern
Providers use factory methods for conditional instantiation:Strategy Pattern
Different OAuth strategies for OAuth 1.0 vs 2.0:Repository Pattern
Database operations abstracted through services:Security Architecture
Authentication & Authorization
Authentication & Authorization
Data Protection
Data Protection
- Database-level encryption
- Encrypted OAuth tokens
- HTTPS for all external communication
- Sensitive data never logged
Access Control
Access Control
- User-scoped data access
- Provider-specific permissions
- API rate limiting
- CORS policies
Secure Communication
Secure Communication
- TLS/SSL for external APIs
- State parameter for OAuth CSRF protection
- Token refresh mechanisms
- Secure session management
Scalability Considerations
Horizontal Scaling
The system supports horizontal scaling:Stateless API
API servers are stateless, enabling horizontal scaling behind a load balancer
Distributed Cache
Redis supports clustering for distributed caching
Database Pooling
Connection pooling enables multiple API instances
Async Processing
Async/await enables high concurrency per instance
Deployment Architecture
Docker Compose Architecture
Monitoring & Observability
Logging
Structured logging throughout the system:Metrics
Track key performance indicators:- Request latency
- Provider success rates
- Data processing throughput
- Error rates by provider
- Token refresh rates
Health Checks
Technology Stack
- Backend
- Storage
- Integration
- DevOps
- Python 3.12+: Core language
- FastAPI: Web framework
- asyncio: Async I/O
- Pydantic: Data validation
- SQLAlchemy: Database ORM
Extensibility Points
The architecture provides multiple extension points:New Providers
New Providers
See Development new health device integrations:
Tools & MCPs
Tools & MCPs
- See Adding Custom Tools to add new tools for AI agents
- See Adding Custom MCPs to add new MCPs for AI agents
Custom Indicators
Custom Indicators
Add new health metrics:
- Define in
StandardIndicatorenum - Specify standard unit
- Update provider mappings
AI Providers
AI Providers
Add new LLM providers:
- Implement provider interface
- Add configuration
- Register in agent system
- Deploy
Best Practices
Separation of Concerns
Each layer has a single responsibility
Dependency Injection
Services injected, not hard-coded
Interface-Based Design
Program to interfaces, not implementations
Configuration-Driven
Behavior controlled via configuration
Async First
Async/await for all I/O operations
Error Handling
Graceful degradation and recovery